Using @version to indicate the schema version

[Markus Demleitner]

Dear Grid,

In a recent discussion
(http://mail.ivoa.net/pipermail/grid/2018-June/002944.html) I noticed
an issue with our brand-new XML schema versioning note,
http://ivoa.net/documents/Notes/XMLVers/.  Let me try to explain:

In schema versioning, the full version string of the schema an
instance document or element is written against is indicated with a
@version attribute.  For instance,

  <ri:Record xsi:type="vs:CatalogService" version="1.2"
      xmlns:vs="http://www.ivoa.net/xml/VODataService/v1.1">
    ...
    <capability xsi:type="tr:TAPCapability" version="1.1"
      xmlns:tr="http://www.ivoa.net/xml/TAPRegExt/v1.0">

would indicate that the VODataService schema actually complies to
version 1.2 of the schema identified by (and for IVOA schemas
available at) http://www.ivoa.net/xml/VODataService/v1.1, and
analogously TAPRegExt to version 1.1 (yes, it's ugly that namespace
URIs appear to indicate other minor versions, but that's a known
problem we can only fix for new, future namespace URIs).

Clients should in general not need to worry about the schema minor
version (at least if they parse according to XML schema versioning
rules), but there are some use cases in which they might care
(validation perhaps, and UWS 1.1 already (ab-)uses that mechanism to
let clients discover that a service supports extra features from UWS
1.1).

There is a trap in this scheme: What happens if a global element or a
type in a schema already has a @version attribute?  This already
happened in the UWSRegExt draft, where Brian inherited from
vr:Interface. In that type, @version denotes the version of a
protocol implemented on an interface.

So, when describing a TAP 1.1 service, by VOResource you would want to
say 

  <interface version="1.1" xsi:type="uws:Sync"...>

because you're speaking TAP 1.1.  However, that interface element is
also the root element of something taken from UWSRegExt 1.0, so by
schema versioning you should say

  <interface version="1.0" xsi:type="uws:Sync"...>

because the element conforms to version 1.0 of the schema.

Boom.

After thinking about this for a bit, there are two possible escape
routes I could come up with:

(a) One possibility would be to say that IVOA schemas just should
never use version attributes for anything but schema versioning.  

In retrospect, the attribute name on interface should probably have
been protocol-version in the first place.  So, if we didn't have the
existing @version attributes I'd say "great, let's do it".  As things
are now, I can't come up with a good plan on how to transistion at
least vr:Interface in a sane way (and there might be other
occurrences of @version in IVOA schemas -- I've not looked yet).

(b) The other way I can see is to namespace schema versioning's
schema attribute.  In the example above, we'd then have

  <interface version="1.1" xsi:type="uws:Sync"
    schema:version="1.0"...>

-- which to my eye even looks pleasant (until I add the namespace
declarations, that is...).

To make this happen, we'd have to fast-track XML schema versioning
2.0 for which I'd volunteer.  As far as I can tell, XML schema
versioning has been used in this way by VOResource 1.1 (for which
takeup isn't that huge so far, so that's probably not much of a
problem; also, I don't think anyone will use @version in the xml
schema sense on VOResource documents) and UWS 1.1.  For that latter
one, I clients do use @version.  We'd have to figure out how much
breakage would be caused if we changed @version to @schema:version.
Still, we *might* just get away with errata for VOResource 1.1 and
UWS 1.1.

Neither option is smooth.  So, any further ideas or opinions are
highly appreciated,

           Markus