Using @version to indicate the schema version

[Brian Major]

Hi Paul,

I've moved this conversation from dm at ivoa.net to the GWS thread Markus
started in June and have added your reply.

Yes, I agree that this should be addressed quickly.  If you have time to
put towards this then please do, and thank you.

Adding the namespace seems like the correct thing to do to me.  Perhaps we
should consider renaming 'version' too?

Cheers,
Brian

On Fri, Aug 24, 2018 at 12:15 AM Paul Harrison <
paul.harrison at manchester.ac.uk> wrote:

>
>
> I have to admit that had passed me by - I think that we should do
> something, before the recommended practice propagates too far  - and as
> Markus says, I don’t think that existing clients will have needed to make
> too much use of this, and in general it will be for small additional
> functionality (though UWS might be the exception). It seems that from an
> XML point of view Markus is also right that it would be better to have the
> “schema” version attribute in a separate namespace, rather than just making
> it part of the namespace of the “host” schema (even with a different local
> name, there is always the possibility of a clash in the same namespace) -
> perhaps it can be put into the StandardsRegExt schema as a standalone
> attribute definition, or even just reuse the one from "
> http://www.w3.org/2001/XMLSchema” (which might be nicest as this is then
> exactly the same attribute in the instance document as the schema itself).
> The only argument against using the namespace is that it does add perhaps
> ~40 characters of extra length to the instance document.
>
> As you can probably tell, I am (perhaps briefly) re-engaged in the VO
> world as I am trying to implement some services, so I don’t mind taking
> this on
>
> Cheers
>         Paul.
>
>
> Dr. Paul Harrison
> JBO, Manchester University
> http://www.manchester.ac.uk/jodrellbank


On Wed, Jun 27, 2018 at 12:09 AM Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20180824/504c2c30/attachment.html>