Using @version to indicate the schema version

[Paul Harrison]

Hi,

There is something that I think needs to be borne in mind when considering this whole matter - the standard/schema can only have a minor change for this mechanism to be relevant - In reality I think that this will only extend to a x.2 version at most - it will be too difficult to find non-breaking additions to a protocol, so it will have to be a major update. So it is unlikely that the instance XML documents will have to signal more than perhaps x.1 and x.2 . It is however possible that the actual schema document does have to have more updates (e.g. to fix technical errata) which was why I always had in mind that the xs:schema/@version had different actual content (see the uws schema as an example), though the original schema versioning note was not very clear about this, and in places make statements that they content should be identical when in fact it is only the major.minor number that should be identical.

> On 2018-08 -31, at 10:28, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> So, for UWSRegExt, which started this whole thing, this would mean
> that the schema would have to look like this:

As you can tell, on reflection I have changed my mind and I do not like UWSRegExt and its proposed use as I think that it throws up contradictions in all sorts of areas
> 
> Reflecting again, I'd suggest no. You see, this will be in, say, a
> TAP capability (with a corresponding standard id of, fantasising,
> TAP#1.2), and so *if* a client cares about a minor version of *UWS*,
> there's no way they can figure this out from the registry record.
> With so many standards going into some of our services, I start
> suspecting that describing all of the versions going in would require
> a new mechanism (or hard-coupling the various standards, which I'd
> find very regrettable).  But I'd hope we don't need minor versions of
> everything.
> 
> In the UWSRegExt case, we could say with async, the stdVersion
> actually corresponds to the version of UWS rather than UWSRegExt or
> VODataService.  
> 
> Which would be automatic if UWSRegExt simply were part of UWS itself
> -- ah, if only the XRegExts were part of the respective standards! 
> 
> The situation is still uglier because
> 
> (a) Sync and Async may become parts of VODataService, which is even
> further decoupled from UWS.
> 
> (b) We have Sync, where there's not a standard that directly governs
> it in the first place.
> 
> So...
> 
> (1) Do we have a use case for discovering minor versions on this
> level (for UWS, I think there is)?
> 
> (2) If there is, my hunch is that even in UWSRegExt (and even more if
> this moves into VODataService) we should be saying "stdVersion of
> Async refers to UWS" and (for lack of a better idea) "stdVersion of
> Sync refers to DALI”.

I think that the client should not be determining this sort of information on the sub-protocols of the main protocol from the registry, as it makes trying to register all the possibilities too difficult, and I agree that it is nice if we can avoid the fact that versions for standards are in complete lock - however, it is true that a particular standard does specify the minimum version of the other standards that it depends on - so focussing on TAP and UWS, the timeline went something like.

1. TAP 1.0 specifies UWS 1.0 for the async endpoint
2. UWS 1.1 allows some extra functionality - and providers are allowed to start using that functionality in TAP1.0 services - however, the only way of discovering that the extra functionality is there for clients is to look for the @version value in the return XML from the instances 
3. TAP 1.1 specifies UWS 1.1 for both the sync and async endpoint  (that is my reading of the standard - which surprises, though pleases, me given the arguments for a “simple” sync endpoint in TAP 1.0)

The situation at point 2 was fine in the case of UWS i.e. the client did not need a registry discovery method for the new version, because if a client cared enough to be able to take advantage of new UWS feature it could always do an initial “job list” query on the endpoint to discover the actual version - So in the particular case of UWS the registering of the exact version used in a particular protocol is completely unnecessary- In general I think that we should arrange things in this way too if possible - only the top level protocol and its version/endpoint is registered, as it simplifies all sorts of things, including the initial discovery query. It is not really a burden on the client to have to call the service endpoint URL to find exact versions if necessary (and it will only do this if it cares about all the nuances that the exact minor versions carry - the service should still broadly work by definition if only the major version is known).

> So, let's go ahead with fixing its text and then revisit the use
> cases we've had so far (UWS, SimpleDALRegExt, VOResource, upcoming
> TAPRegExt and UWSRegExt; any others?).  And let's in particular think
> hard what this means for VOTable, where I hope we'll keep the 1.3
> namespace URI, and where there's been a version attribute for quite a
> while.  Anyone up for visiting an Apps session in College Park and
> asking what people do with VOTABLE/@version?[1]
> 

Was there not the fairly radically new version of VOTable in the wings that has all the VO-DML mapping stuff in it? VOTable might have to be a special case, as the practice so far has to issue new namespaces for minor updates anyway….

> [1] Not me -- I won't make it to College Park, sorry.

nor me unfortunately.

Cheers,
	Paul.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180905/1e17b9fa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1905 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180905/1e17b9fa/attachment.p7s>