Backwards incompatible changes in VOTable 1.2

Francois Ochsenbein francois at cdsarc.u-strasbg.fr
Wed Jul 11 01:53:36 PDT 2012


Hi,

Yes, the essential requirement of supporting streaming processing
was the main motivation. As Sebastien pointed out, the problem
occurs only in the case where a RESOURCE does not contain any table
(i.e. contains only a description of a resource, but no description
of the table(s) the resource includes) AND contains at least one LINK
(which in the Aladin context describes how to query vizier). 
In this case only, an empty TABLE or RESOURCE is required, in order
to be compatible with the UPA requirements Sebastien pointed out.

Cheers, francois

>
>Hi Thomas,
>
>I'd guess the changes were made to support streaming of VOTable responses.  E.g.,
>in TAP an INFO element after the table results indicates that the query results
>are incomplete if the query results exceed the user's limit on the number of rows.
>If INFO elements are only allowed at the beginning we can't begin writing results
>until the query is finished.  Supporting streaming seems like a worthy goal, but
>perhaps it could have been done in some more compatible way.  Sebastien's link
>suggests that a new version of the schema standard might resolve the amgibuities
>in the schema in a way that would restore compatibility, but presumably that's not
>likely to happen on a useful time scale.
>
>	Regards,
>	Tom
>
>Thomas Boch wrote:
>> Hi,
>>
>> I recenty found out (at my expense) that the VOTable 1.2 schema
>> introduced some backwards incompatible changes with respect to earlier
>> versions of the standard.
>> The following structure :
>> <RESOURCE>
>>    <INFO name="foo" value="fooValue"></INFO>
>>    <INFO name="bar" value="barValue"></INFO>
>>    <LINK action="http://mydomain.com/mylink" />
>> </RESOURCE>
>>
>> is valid in VOTable 1.1 but is invalid in VOTable 1.2
>>
>> It seems that the issue comes from changes made in order to allow INFO
>> elements before the closing tags /TABLE, /RESOURCE and /VOTABLE.
>> Was there a strong enough use case for introducing a change which breaks
>> backwards compatibility ?
>> I feel that this incompatibility should be clearly and proeminently
>> pointed out in the VOTable document.
>>
>> Cheers,
>>
>> Thomas
>>
>
=======================================================================
Francois Ochsenbein    ------   Observatoire Astronomique de Strasbourg
   11, rue de l'Universite 67000 STRASBOURG  Phone: +33-(0)368 85 24 29
Email: francois at cdsarc.u-strasbg.fr (France)    Fax: +33-(0)368 85 24 17
=======================================================================


More information about the apps mailing list