VOTable 1.4 schema inconsistencies

[Francois Ochsenbein]

Hello,

Just along the same remarks that the XSD schema should prevail, VOTable 
version 1.2 included the following sentence at the beginning of
section 7:

``The XML Schema represents the actual definition of a VOTable document.
In this section we illustrate this XML Schema by a set of boxes
describing the structure of a VOTable, and the list of attributes of
each VOTable element.''

Best regards to veterans and new IVOA friends 😊

François Ochsenbein

==> Le lundi 2019-04-01 à 08:27+0000,
    Mark Taylor <M.B.Taylor at bristol.ac.uk> a écrit:

>Tom,
>
>I agree with your approach of updating the diagram where possible and
>leaving the schema as is.  I confess to never having looked in great
>detail at these diagrams; they are kind of useful though obviously
>not as rich or precise as an XSD in defining what's legal.
>You mention the idea of adding a note to that effect in section 7.1;
>a possibility would be to include a comment that in case of
>any discrepancies between the schema and the diagram, the schema
>is definitive (or equivalently to mark section 7.1 as non-normative).
>I'm pretty sure this is what readers would assume anyway, but it
>might avoid potential confusion to make that explicit.  But up to
>you whether you think that's a good idea.
>
>Mark
>
>On Sun, 31 Mar 2019, Tom Donaldson wrote:
>
>> Hi All,
>> 
>> While implementing a minor tweak to the INFO element in section 5
>> (see proposed change at
>> https://wiki.ivoa.net/twiki/bin/view/IVOA/VOTable14WorkingDraftNotes
>> ), I noticed two (no three) inconsistencies between the VOTable
>> schema and diagrams in section 7.1.
>> 
>> My hope is change as little as possible now, but please see and
>> comment on my proposals for each case.
>> 
>> In general, I hope that VOTable 2.0 takes a new approach to many of
>> these complexities.  In particular, I hope we can remove any
>> flexibility that is not absolutely needed to support a well-defined
>> use case or that does not have well-defined semantics.  A test suite
>> of legal and illegal VOTables would be useful, but also a lot of
>> effort to create and maintain.  But all that's for another day...
>> 
>> Regards,
>> Tom
>> 
>> 
>> 1) Position of INFO element inside RESOURCE:
>> 
>> The diagram in section 7.1 says that inside RESOURCE, the INFO,
>> COOSYS, TIMESYS, GROUP and PARAM elements can appear in any order
>> relative to each other.  The schema however requires that INFO
>> appear before any of those other element (i.e., INFO is part of the
>> sequence, but not part of the choice).  The current schema renders
>> illegal the placement of INFO in Section 5.
>> 
>> This restrictiveness seems to have been added to the schema in
>> VOTable 1.2.  This is also inconsistent with the VOTABLE element
>> where the schema agrees with the diagram and allow flexible ordering
>> of INFO.
>> 
>> Proposal:  Update the diagram to match the schema.  With that
>> approach, any provider or consumer that relied on the schema or
>> votlint would be OK.  If providers relied on the diagram in the
>> past, their VOTables would already have been rejected by consumers
>> that relied on the schema.
>> 
>> 
>> 2)  Relative positions of LINK, TABLE, RESOURCE and INFO inside
>> RESOURCE:
>> 
>> The diagram says that a RESOURCE can end with any number LINKs,
>> followed by any number of TABLEs, followed by any number of
>> RESOURCEs, followed by any number of INFOs.  In the schema, those
>> elements are inside of a repeatable sequence, so the ordering is
>> substantially more flexible than the diagram indicates, but not
>> totally flexible due to the TABLE/RESOURCE choice in the sequence.
>> 
>> For example, this is legal:
>> 
>> 		<COOSYS ID="mycoords"/>
>> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
>> 		<INFO name="info" value="info"/>
>> 		<LINK/>
>> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
>> 
>> But this is not:
>> 
>> 
>> 		<COOSYS ID="mycoords"/>
>> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
>> 		<LINK/>
>> 		<INFO name="info" value="info"/>
>> 		<TABLE><FIELD name="f1" datatype="int"/></TABLE>
>> 
>> Proposal:  Leave the schema as is for the same reasons as case #1.
>> But also leave the diagram as is since we don't have existing
>> diagram techniques to describe what the schema says.  Perhaps a note
>> in that section trying to explain that could be helpful.  Repeating
>> these particular elements is probably extremely rare, so what we do
>> may not matter much for current implementations.
>> 
>> 
>> 3)  While writing this, I noticed yet another inconsistency between
>> the diagrams and the schema.  The diagrams claim that TABLE has no
>> required children, but the schema requires that one of FIELD, PARAM
>> or GROUP be present.
>> 
>> Proposal:  Do nothing.  A TABLE without a FIELD, PARAM or GROUP is
>> not worth worrying about.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>
>--
>Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
>m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/


-- 
======================================================================
Francois Ochsenbein  ---   6, rue des Vosges -- 67380 Lingolsheim 
ochsenbein at evc.net   ---   francois.ochsenbein at gmail.com
+33 (0)388 77 81 17  ---   +33 (0)602 39 60 78
======================================================================