VOTable 1.4 schema inconsistencies

[Mark Taylor]

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/