<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi all,<br>
<br>
I would like to add my 2 cents from my perspective, as a client
application developer.<br>
<br>
1. One thing I quite like about STC-S description is that it is
self-contained, the string by itself is sufficient for a reasonably
smart client to make something useful with it, for instance display
it on the sky.<br>
<br>
2. I'm a bit worried that having different ways of expressing
roughly the same thing (the region on the sky covered by an
observation) goes against interoperability and makes client
implementation more difficult.<br>
<br>
Please take my comments with a grain of salt as I might not have in
mind the big picture of how DAL protocols are interlinked.<br>
<br>
Cheers,<br>
<br>
Thomas<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Le 27/11/2017 à 13:12, François
Bonnarel a écrit :<br>
</div>
<blockquote
cite="mid:5920ba72-5797-f823-5c5c-dfdf2cf14e7a@astro.unistra.fr"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>Dear all,</p>
<p>My understanding of this context as a DAL chair involved in
several of the specifications as author and (supposed to be)
aware of the others.</p>
<p>Most of this stuff is extracted from a discussion we had in a
more limited group.<br>
</p>
<p>1 ) Obscore<br>
</p>
<p> The discussion here is actually invloving at least 3 DAL
standards + Obscore (which is DM oficially but actually
"DM-DAL") : TAP, ADQL, DALI and Obscore. The DAL dillemma is the
following : as it encompasses a vast variety of situations and
use cases and various interface shapes, DAL technology cannot be
defined by a single "SPEC_OF_EVERYTHING". DAL has defined a
great deal of different protocols, which of them evolving its
own rythm. We have to be carefull all this keep consistent and
to be carefull also we do not break everything <br>
</p>
<p> Each of the 4 standards involved here have two versions :
TAP 1.0, 1.1, ADQL 2.0, 2.1, DALI 1.0, 1.1. Obscore 1.1 and DALI
1.1 are IVOA recommendations since 2017 May the 17th. TAP1.1 and
ADQL 1.1 are still in discussion.</p>
<p> 1 ) For s_region what does Obscore spec says ? ObsCore is
a model (or a view of a larger model) each class/attribute is
perfectly defined. To map such a model in a TAP service one has
to express it in a TAP schema. The OBscore spec defines
precisely this TAP schema. + xtypes for each TAP schema column.
In OBscore 1.0 the xtype for s_region is "adql:REGION". Obscore
1.1 maintains the same definitions for s_region (and other
ObsCore attributes) than 1.0. But it adds that the definition
given in the spec is consistent with TAP 1.0 (the only valid one
at the moement it was defined) but that the situation may evolve
after the release of TAP 1.1.</p>
<p> 2 ) So what does TAP says about xtypes ? 1.0 was defining
a couple of them, all bound to adql functions, including
adql:Region. adql:REGION WAS AT THE TIME OF WRITING OF 1.0
considered as STC-S. TAP 1.1 gets rid of this and claims that as
far as possible xtype should map to the definitions given in
DALI. It says "SHOULD" and not MUST of course. You are still
allowed to define or use other xtypes if really necessary.</p>
<p> 3 ) DALI 1.0 didn't say anything about xtypes. DALI 1.1
defines a couple of them. xtypes CIRCLE and POLYGON are defined
as arrays of doubles. This has also been discussed to be xtypes
of some of SODA input parameters (together witn interval). These
xtypes are those refered by TAP 1.1 as those that SHOULD be
used if no other xtype is required by the use case.<br>
</p>
<p> 4 ) ADQL 2.0 Defined a couple of functions which TAP was
mapping to xtypes: Among them REGION. ADQL 2.1 is considering
dropping string-typed REGION and keep more double array oriented
CIRCLE and POLYGON. This has consequences for querying. This has
no consequence on adql:REGION xtype which can remain defined as
in ADQL 2.0 if necessary.<br>
</p>
<p><br>
</p>
<p> Discussion :</p>
<p> With the main goal of keeping the
defintions and formats stable for a while in the vO in a given
context ( the ObsCore/OBstap one here) I think nothing prevent
us to keep adql:REGION (equivalent to STC-S string) as an xtype
for the s_region attribute in ObsCore. <br>
</p>
<p> I don't know how DACHS is implemented
but I assume it generates xtypes in the VOTABLE response of the
services from the TAP schemata. So if the the ObsCore TAP schema
keeps adql:REGION as the xtype of s_region instead of
xtype=polygon, clients like Aladin could still recognize and
parse it immediatly.</p>
<p> Actually it makes more sense than it may
appear. The data/metadata (coord system and whatever)
distinction is not an issue for Obscore. Everything is ICRS in
there. So the STC-S string is unambiguously a polygon, a circle,
or any of other stc flavors of space area perfectly
understandable. s_region is not only a space area. It's the
support of the observation (as defibed by ObsCore and
characterisation) expressed as a space area. So it's not that
strange to have a spoecific xtype for it, and to keep the
historical adql:REGION/STC-S then.</p>
<p> For POlygon or CIRCLES in general,
which have plenty of usages different from "dataset support"
(exemply gratia "region of interest", "survey or catalog
coverages" , "cross match search regions" ,etc... and which may
require different coordinate systems than ICRS going to the
POLYGON/CIRCLE xtypes with arrays is the most standard option
for the future...</p>
<p>Lets' go to Pierre questions in detail<br>
</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">Le 24/11/2017 à 12:26, Pierre
Fernique a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:f3a251f5-ac8a-b9a0-f5d3-57d7bd093cdb@astro.unistra.fr">
<meta http-equiv="Context-Type" content="text/html;
charset=utf-8">
<p><br>
</p>
<p>Dear DAL and Apps members,</p>
<p>It seems that we have a problem concerning the <b>s</b><b>_region</b>
usage.</p>
<p>Recently, we discover that some data providers have changed
their syntax, moving from the regular STC-S string to a new
one which seems to be an array of doubles, alternating long
and lat. Both Aladin V10 and Aladin Lite fail to manage a such
new syntax, and we had complaints from final users which do no
longer see the FoV of their observations.</p>
<p>After investigating about this unexpected evolution, it
appears that this new syntax is generated by some versions of
DaCHS testing TAP1.1 future possible recommendation.</p>
<p>So, I have several questions for TAP 1.1 authors and DAL
members :<br>
</p>
<ol>
<li>Is is really true that STC-S s_region should be removed
from VOTable results ? Personally, I did not see this
consequence in the TAP 1.1 document. or ?<br>
</li>
</ol>
</blockquote>
No. Nothing prevent us to have string field in VOTable<br>
<blockquote type="cite"
cite="mid:f3a251f5-ac8a-b9a0-f5d3-57d7bd093cdb@astro.unistra.fr">
<ol>
<li> <br>
</li>
<li>And if yes : is it only in TAP ? or also in SIA2 or SSA ?</li>
</ol>
</blockquote>
TAP itself doens't prevent to use string-typed FIELDS in the
response. IT only recommands usage of fIELDS with wtype. <br>
In the case of s_region the basic thing is not TAP or SIAV2, the
discovery protocol, but ObsCOre. ObsCore has to be stabilized. <br>
Common discovery metadata in the case of ADQL queries and the case
of Parameter query language has been a major progress recently...<br>
We should not break it/<br>
<br>
For SSA si next answer.<br>
<blockquote type="cite"
cite="mid:f3a251f5-ac8a-b9a0-f5d3-57d7bd093cdb@astro.unistra.fr">
<ol>
<li>How the client can know the logic (lon/lat or lat/lon,
counter-clock or anti-counterclock, ...), the frame and
other coordinate parameters for such array of double ?</li>
</ol>
</blockquote>
I think xtype=POLYGON assumes it's lon/lat. At the moment
coordsystem can aonly be given by the de-deprecated COOSYS. So
reference to a COOSSYS element seems to be the only solution.<br>
<blockquote type="cite"
cite="mid:f3a251f5-ac8a-b9a0-f5d3-57d7bd093cdb@astro.unistra.fr">
<ol>
<li>How providers who already generated complex s_region will
do now ? (for instance ESO)</li>
</ol>
</blockquote>
I think they should not change that. ObsCore has been designed and
discussed durin a long time to be a stable basis.<br>
<blockquote type="cite"
cite="mid:f3a251f5-ac8a-b9a0-f5d3-57d7bd093cdb@astro.unistra.fr">
<ol>
<li> <br>
</li>
<li>How we will manage the transition period ?</li>
</ol>
</blockquote>
In my opinion no transition period is needed for the specific case
of s_region which is STCS ICRS.<br>
<br>
DAL "build up" is always a balance between stability and backward
compatibility and controlled progress in the definitions.<br>
<br>
Cheers<br>
François<br>
<blockquote type="cite"
cite="mid:f3a251f5-ac8a-b9a0-f5d3-57d7bd093cdb@astro.unistra.fr">
<ol>
</ol>
<p>Best regards<br>
Pierre Fernique</p>
<p><br>
</p>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>