VOTable 1.4 schema inconsistencies

[Gerard Lemson]

As an aside regarding the XSD.
There are still a bunch of comments in there that I made >>10 years ago when we rewrote the schema.
Most prefixed by "GL:". I think it might be nice to finally remove these in the next version.
Cheers
Gerard



> -----Original Message-----
> From: apps-bounces at ivoa.net [mailto:apps-bounces at ivoa.net] On Behalf Of
> Francois Ochsenbein
> Sent: Monday, April 01, 2019 7:46 AM
> To: Mark Taylor <M.B.Taylor at bristol.ac.uk>
> Cc: Applications WG <apps at ivoa.net>
> Subject: Re: VOTable 1.4 schema inconsistencies
> 
> 
> 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
> ================================================================
> ======