Changes to VOTable 1.4 Working Draft

[Markus Demleitner]

Hi Tom,

On Thu, Feb 14, 2019 at 04:23:59PM +0000, Tom Donaldson wrote:
> A stand-alone validator *should* care about minor versions,
> validating against the schema identified by the version attribute.
> For example, if my VOTABLE has version="1.3" and also includes a
> TIMESYS element, then ideally a validator would flag an error.

That is a reasonable use case, that, as far as I can see, is not
sufficiently addressed in the XML Versioning Policies so far.

We'll have a new version of them soon-ish anyway, I guess; I seem to
remember that Paul Harrison has volunteered to iron out a few ugly
spots.  This "@version-based validation" use case could go in there
while we're in fixing mode anyway.  Also, I think I have an idea of
how to properly do it [essentially: Standards *also* publish URLs at
which minor version-sharp schema files can be downloaded but
discourage their use anywhere in instance documents or production
software; there, only the namespace URI without a minor version is
visible.]

I'd *really* like to keep this out of VOTable 1.4 as far as possible,
though.  I'm also pretty sure custom validators are possible without
any hacks with what we have in VOTable, viz,

* http://ivoa.net/xml/VOTable/votable-1.4.xsd  as the location of
  the machine-readable schema; this would, for instance, be hard-coded 
  into the validator as the schema associated to @version="1.4"[1]
* <VOTABLE version="1.4" xmlns="http://ivoa.net/xml/VOTable/v1.3">
  as the root of production VOTables.
* An (ideally unversioned) reference to XML Versioning Policies where
  the scheme is explained in more depth for those needing to dig in
  deeper.

      -- Markus

[1] I'd argue hard-coding "official" schema URIs into software is
what we want to do here, anyway.  Alternatives I could come up with:

* Accepting arbitrary schemaLocations won't tell us anything about
  document compliance because people could give you their custom
  mogrifications of VOTable schemas (I regularly do that).  
* Fixing schemaLocation to some "official" value just
  multiplies the number of locations the official URL needs to be
  hardcoded, which seems unwise to me.