Implications for VOEvent schema?

[Rob Seaman]

Hi,

Does this VOTable UPA issue have any implications for VOEvent?

Rob
--

Begin forwarded message:

> From: Sebastien Derriere <sebastien.derriere at astro.unistra.fr>
> Subject: Re: Backwards incompatible changes in VOTable 1.2
> Date: July 10, 2012 1:44:45 AM MST
> To: votable at ivoa.net
> Cc: apps at ivoa.net
> 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20120710/240fa1dc/attachment.html>