<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<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>
</body>
</html>