<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hi again,</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">addendum on impact assessment.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Less than 1% of all services return a VOTable </div><div class="gmail_default" style="font-family:monospace">version 1.2+.</div><div class="gmail_default" style="font-family:monospace">Removing cds.vizier's ones the percentage </div><div class="gmail_default" style="font-family:monospace">raises to ~10%.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Again, server side impact seems not a concern,</div><div class="gmail_default" style="font-family:monospace">also because the erratum won't deprecate </div><div class="gmail_default" style="font-family:monospace">VOTable versions 1.0 and 1.1, but simply </div><div class="gmail_default" style="font-family:monospace">allow for higher minor versions.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">I don't know how to check on the client side.</div><div class="gmail_default" style="font-family:monospace">I used PyVO for the results above and I remember </div><div class="gmail_default" style="font-family:monospace">working with TOPCAT with services taken into </div><div class="gmail_default" style="font-family:monospace">account in the above with versions > 1.1.</div><div class="gmail_default" style="font-family:monospace">Same way, I think Aladin should be fine.</div></div><div><br></div><div><div class="gmail_default" style="font-family:monospace">But how to do a reliable client side check, </div><div class="gmail_default" style="font-family:monospace">I'm unsure. Cross-post to Apps?</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Cheers</div><div class="gmail_default" style="font-family:monospace"> Marco</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno gio 18 nov 2021 alle ore 16:42 Molinaro, Marco <<a href="mailto:marco.molinaro@inaf.it">marco.molinaro@inaf.it</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-family:monospace">Hi,</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">I tend to agree with Mark here, maybe finding </div><div style="font-family:monospace">a way to stress we are referring to VOTable-1.x </div><div style="font-family:monospace">(is there a risk for VOTable-2.x?).</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">The "binary" issue I consider similar to the </div><div style="font-family:monospace">mime type one.</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">I made a rough attempt, by "authority" of </div><div style="font-family:monospace">ConeSearch resources (hoping for some homogeneity </div><div style="font-family:monospace">in the service tooling used when grouping </div><div style="font-family:monospace">services that way).</div></div><div><br></div><div><div style="font-family:monospace">It turns out (exceptions apart) that most </div><div style="font-family:monospace">ConeSearches serve VOTable-1.1, a few (1?)</div><div style="font-family:monospace">VOTable-1.0, but there are quite a number </div><div style="font-family:monospace">issuing VOTable-1.2, 1.3 and even 1.4.</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">I'll try a finer check (not sure I'll succeed), </div><div style="font-family:monospace">but I'd say the impact assessment looks safe </div><div style="font-family:monospace">from the above skinny result.</div><div style="font-family:monospace"><br></div><div style="font-family:monospace">Cheers</div><div style="font-family:monospace"> Marco</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno gio 18 nov 2021 alle ore 15:35 Mark Taylor <<a href="mailto:m.b.taylor@bristol.ac.uk" target="_blank">m.b.taylor@bristol.ac.uk</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 18 Nov 2021, Markus Demleitner wrote:<br>
<br>
> Hi Marco,<br>
> <br>
> On Wed, Nov 17, 2021 at 01:19:59PM +0100, Molinaro, Marco wrote:<br>
> > I took the liberty to draft the erratum:<br>
> > <br>
> > <a href="https://wiki.ivoa.net/twiki/bin/view/IVOA/SCS-1_03-Err-2" rel="noreferrer" target="_blank">https://wiki.ivoa.net/twiki/bin/view/IVOA/SCS-1_03-Err-2</a><br>
> <br>
> Thanks for making that move. I've expanded the erratum a bit, and<br>
> I'd now be happy with it.<br>
<br>
I prefer Marco's original<br>
<br>
"The XML content of the response must be compliant with the<br>
VOTable Recommendation."<br>
<br>
over Markus's suggested:<br>
<br>
"Simple Cone Search services MUST return VOTable version 1 documents.<br>
This means that clients will have to handle the namespace URIs<br>
<a href="http://www.ivoa.net/xml/VOTable/v1.1" rel="noreferrer" target="_blank">http://www.ivoa.net/xml/VOTable/v1.1</a>,<br>
<a href="http://www.ivoa.net/xml/VOTable/v1.2" rel="noreferrer" target="_blank">http://www.ivoa.net/xml/VOTable/v1.2</a>, and<br>
<a href="http://www.ivoa.net/xml/VOTable/v1.3" rel="noreferrer" target="_blank">http://www.ivoa.net/xml/VOTable/v1.3</a>, where the last namespace<br>
will be used for all future VOTable 1 versions.<br>
For forward compatibility clients should ignore unknown elements<br>
and attributes in these documents as per the IVOA schema versioning<br>
policies."<br>
<br>
Marco's version is simpler and preserves the parts of the intent of<br>
the original that we want to preserve, and is probably what the<br>
original authors would have written if they'd been thinking about<br>
these things. I don't think we need a lot of explanation to help<br>
people out here (the impact assessment is that everything's working<br>
OK anyway), we just need to unbend from the existing version restrictions.<br>
<br>
I'm dubious also about Markus's mention of BINARY serialization,<br>
only to point out that it's not relevant here:<br>
<br>
"We note that, in particular, the main interoperability problem even<br>
in the days of SCS 1.03, lack of support for BINARY-serialised tables,<br>
is orthogonal to the problem addressed here, as BINARY serialisation<br>
was already part of VOTable 1.1."<br>
<br>
I would therefore prefer to delete the middle paragraph of the r2<br>
impact assessment.<br>
<br>
> > I'll try to work a bit better on the impact assessment<br>
> > (if you already have some numbers there it would help).<br>
> > I remember many services already returned VOTable-1.3.<br>
> <br>
> Right -- the EuroVO validation service should give this number in one<br>
> click, as I think "wrong VOTable version" is one specific criterion<br>
> there.<br>
> <br>
> But I have to admit I just spent five minutes to find these stats on<br>
> <a href="http://registry.euro-vo.org" rel="noreferrer" target="_blank">registry.euro-vo.org</a> or in the Ops sessions of the last three<br>
> interops and failed. Can anyone help out there?<br>
<br>
I spent >5 minutes and failed too. I suspect that this problem is<br>
coded as one of the val_codes 2.2c-i, 2.2c-ii or 2.2c-ii,<br>
as shown by e.g. ivo://<a href="http://archive.stsci.edu/catalogs/2mass" rel="noreferrer" target="_blank">archive.stsci.edu/catalogs/2mass</a><br>
(<a href="http://gsss.stsci.edu/webservices/vo/ConeSearch.aspx?CAT=2MASS" rel="noreferrer" target="_blank">http://gsss.stsci.edu/webservices/vo/ConeSearch.aspx?CAT=2MASS</a>),<br>
but I can't work out the mapping from those val_codes to a verbal<br>
description of the issue being checked.<br>
<br>
Mark<br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bristol.ac.uk" target="_blank">m.b.taylor@bristol.ac.uk</a> <a href="http://www.star.bristol.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bristol.ac.uk/~mbt/</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><font face="monospace">Marco Molinaro</font></div><div><font face="monospace">INAF - Istituto Nazionale di AstroFisica</font></div><div><font face="monospace">Osservatorio Astronomico di Trieste</font></div><div><font face="monospace">email <a href="mailto:marco.molinaro@inaf.it" target="_blank">marco.molinaro@inaf.it</a></font></div><div><span style="font-family:monospace">tel. [+39] 333 33 20 564 / 040 3199 152</span><br></div></div></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><font face="monospace">Marco Molinaro</font></div><div><font face="monospace">INAF - Istituto Nazionale di AstroFisica</font></div><div><font face="monospace">Osservatorio Astronomico di Trieste</font></div><div><font face="monospace">email <a href="mailto:marco.molinaro@inaf.it" target="_blank">marco.molinaro@inaf.it</a></font></div><div><span style="font-family:monospace">tel. [+39] 333 33 20 564 / 040 3199 152</span><br></div></div></div></div></div></div></div>