Lifting 1.1 limit in SCS?

Fri Nov 19 10:38:43 CET 2021

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