<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>