Lifting 1.1 limit in SCS?

[Molinaro, Marco]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20211118/1581b03c/attachment.html>