Lifting 1.1 limit in SCS?

Fri Nov 19 10:42:14 CET 2021

TOPCAT, STILTS, anything based on STIL will be fine with this change.
I can't speak for other clients, but my guess is that anything not
based on XML binding or similar ought to be unaffected as well;
I would be fairly surprised if there are client-side issues out there.

A cross-post to Apps sounds like a good idea though.

On Fri, 19 Nov 2021, Molinaro, Marco wrote:

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

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/