Backwards incompatible changes in VOTable 1.2

[Sebastien Derriere]

Le 10/07/2012 08:59, Thomas Boch a écrit :
> 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.

   Hello Thomas and others,

   I also banged my head on this a little while ago. From what I
understood, it results from a strong constraint imposed in XML
schemas called Unique Particle Attribution :
http://en.wikipedia.org/wiki/Unique_Particle_Attribution
   If I get it right, an element in an XML document should be
parseable when it occurs, without need to look further in the
document for any possible disambiguation.
   In VOTable 1.2, <INFO> elements may appear (optionally) in
different places in a Resource, and this causes the problem.

   The 1.1 schema says that a RESOURCE contains a sequence of :
- DESCRIPTION (optional)
- a choice of INFO, COOSYS or PARAM, optional and possibly multiple
- LINK optional and possibly multiple
- TABLE optional and possibly multiple
- RESOURCE optional and possibly multiple - makes RESOURCE recursive
- ##other

   In 1.2, the definition of RESOURCE has changed to a sequence of :

- DESCRIPTION (optional)
- INFO optional and possibly multiple
- a choice of COOSYS, GROUP or PARAM, optional and possibly multiple
- an (optional, possibly multiple) subsequence of :
	- LINK optional and possibly multiple
	- a choice of TABLE or RESOURCE -- NOT optional !!
	- INFO optional and possibly multiple
- ##other

   In terms of schema, because of the UPA constraint, the TABLE or
RESOURCE is mandatory in the (optional) sub-sequence in order to
remove the ambiguity otherwise created by the two elements with
the same name --INFO-- appearing in two different places. So if
you put a LINK in a resource, you *must* provide either a TABLE
(with some of its substructure) *or* a sub-RESOURCE immediately
following this LINK. If the TABLE/RESOURCE choice in the subsequence
was also optional (minOccurs="0"), then all elements in the RESOURCE
would be optionals, and the parser could not determine when reading
an INFO element which one it is in the schema, breaking the UPA rule.
   This makes 1.1 documents such as the one quoted by Thomas not
backward compatible.

   I think the reason was to allow for INFO elements in different
places in VOTable, before or after a TABLE in a Resource, all optional.

   But having to write the following in 1.2 feels cumbersome :

<RESOURCE>
   <INFO name="foo" value="fooValue"></INFO>
   <INFO name="bar" value="barValue"></INFO>
   <LINK action="http://mydomain.com/mylink" />
   <RESOURCE />
</RESOURCE>

-- 

    (((    Sebastien Derriere     sebastien.derriere at astro.unistra.fr
   (. .)   Observatoire de Strasbourg       Phone +33 (0) 368 852 444
  (( v ))  11, rue de l'universite        Telefax +33 (0) 368 852 417
---m-m--- F-67000 Strasbourg  France