<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Hi Alberto,</div><div><br></div><div>in spite of my delayed answer, I fully agree with your statements (all of them, include your extra point). </div><div><br></div><div>Baptiste </div><div><br>Le 7 déc. 2017 à 12:14, alberto micol <<a href="mailto:amicol.ivoa@googlemail.com">amicol.ivoa@googlemail.com</a>> a écrit :<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">Dear All,<div class=""><br class=""></div><div class="">I think that this topic has the potential for a very bad impact on the way the astronomical community perceives the VO.</div><div class=""><br class=""></div><div class="">1.- The clients/tools are the face of the VO, they are what the astronomical community sees of the VO.</div><div class=""><div class="">Exposing these new polygon format when the clients/tools are not yet in the position of digesting it</div><div class="">seems not a good way forward.</div><div class="">We are losing our face with the astronomical community by acting this way.</div><div class="">Coordination with the developers of tools/clients is of paramount importance.</div><div class="">This to me is an important lesson learned.</div></div><div class=""><br class=""></div><div class="">2.- The ObsTAP promise was and still is:</div><div class="">- one and the same query to all data centres,</div><div class="">- one and the same answer (names, formats, units) from all of them</div><div class="">Easy.</div><div class="">This is now an unfulfilled promise.</div><div class=""><br class=""></div><div class="">3.- A multiplication of formats makes it very hard to interoperate.</div><div class="">Some clients will support all new formats, some will only support one of them;</div><div class="">as a consequence, data providers will have to generate output containing all formats</div><div class="">so to guarantee maximum flexibility to their users. Complexity is nobody’s friend.</div><div class=""><br class=""></div><div class="">4.- At ESO, complementing what Theresa said, there was quite some effort in supporting STC-S</div><div class="">as output format from our SQLServer database. We did that because this is required by ObsCore,</div><div class="">and because this is what the clients understand. Blood went into our design and implementations:</div><div class="">STC-S is formally not an approved standard? It is a de-facto standard, and that should be respected. </div><div class=""><br class=""></div><div class="">Sorry all, I might sound a bit hard on all this… apologies but I see a lot at stake here.</div><div class=""><br class=""></div><div class="">Conclusions:</div><div class=""><div class="">I plea the data centres that already implemented the change in Obscore/SSA/SIA/etc</div><div class="">to retract it asap to avoid this confusion, until the impasse</div><div class="">--from the user's point of view-- is resolved. </div></div><div class=""><br class=""></div><div class="">Alberto</div><div class=""><br class=""></div><div class="">PS: One extra point: if you really really really want to move away from STC-S,</div><div class="">then why re-inventing the wheel and coming up with yet a new format?</div><div class="">Please consider to use the well-established text markup language called Well-Known Text (WKT),</div><div class="">already supported by many DBMSes including postgres, SQLServer,</div><div class="">Oracle, mysql, and many others;</div><div class="">see: <a href="https://en.wikipedia.org/wiki/Well-known_text" class="">https://en.wikipedia.org/wiki/Well-known_text</a> (and its RDBMS section).</div><div class="">Such choice would greatly simplify the adoption of the new standard by the data centres:</div><div class="">there would be no need to develop special functions to handle VO-made formats.</div><div class="">Still, clients would have to implement it, but at least the backend job would be already done.</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 24 Nov 2017, at 12:26, Pierre Fernique <<a href="mailto:Pierre.Fernique@astro.unistra.fr" class="">Pierre.Fernique@astro.unistra.fr</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="content-type" content="text/html; charset=utf-8" class="">
<div bgcolor="#FFFFFF" text="#000000" class=""><p class=""><br class="">
</p><p class="">Dear DAL and Apps members,</p><p class="">It seems that we have a problem concerning the <b class="">s</b><b class="">_region</b>
usage.</p><p class="">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 class="">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 class="">So, I have several questions for TAP 1.1 authors and DAL members
:<br class="">
</p>
<ol class="">
<li class="">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 class="">
</li>
<li class="">And if yes : is it only in TAP ? or also in SIA2 or SSA ?</li>
<li class="">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 class="">How providers who already generated complex s_region will do
now ? (for instance ESO) </li>
<li class="">How we will manage the transition period ?</li>
</ol><p class="">Best regards<br class="">
Pierre Fernique</p><p class=""><br class="">
</p>
</div>
</div></blockquote></div><br class=""></div></div></blockquote></body></html>