<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<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>
<li>And if yes : is it only in TAP ? or also in SIA2 or SSA ?</li>
<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>
<li>How providers who already generated complex s_region will do
now ? (for instance ESO) </li>
<li>How we will manage the transition period ?</li>
</ol>
<p>Best regards<br>
Pierre Fernique</p>
<p><br>
</p>
</body>
</html>