Using @version to indicate the schema version

Paul Harrison paul.harrison at manchester.ac.uk
Thu Sep 6 10:16:56 CEST 2018



> On 2018-09 -06, at 05:58, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> Hi Paul,
> 
> On Wed, Sep 05, 2018 at 12:55:06PM +0000, Paul Harrison wrote:
>> 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
> 
> No, I don't think we should expect that.  The rules in schema
> versioning are written such that we should be able to do quite a bit
> of evolution, and that's a good thing because propagating changes in
> namespace URIs is hard in the VO.

I am not saying that it is impossible to have higher standard minor versions, but that it gets increasingly difficult only to add new features that are significant without breaking old ones.
> 
> Take VOTable: Had we had the schema versioning policy from the start,
> I'm pretty sure we'd still have the original VOTable namespace URI
> from 2003 or so now, in version 1.3, and we'd try hard to keep it for
> 1.4.

Quite possibly true - however, it then becomes a matter of judgement as to how long you want to leave deprecated features in the schema (and as soon as they are removed then the whole “soft versioning" mechanism breaks).

Incidentally it has struck me that we better check the schema note to make sure that it does not accidentally forbid sticking at a minor version in the namespace.
> 
>> 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
> 
> Hm -- but then @version would again refer to the schema version
> rather than the document/standard version.  And while for the latter
> we have seen use cases (UWS), I'm still unsure there is a case for
> annotating the precise schema version in document.

The VOSI tables schema is a good example of where they should be different - the current 1.1 version of the schema does not have a @version attribute on the tableset or table elements to specify which version of the VOSI standard the reply conforms to (important because of the ability to reply with only table names in 1.1), so a new version of the schema needs to be created that has the version attribute added - I would say that the xs:schema/@version should be “1.1-err1-REC-20180920” or something similar - perhaps just a 3rd level of dotted version “1.1.1-REC-20180920” is cleaner - then the actual URL that the schema would be available at would be http://www.ivoa.net/xml/VOSITables/VOSITables-v1.1.1.xsd as a redirect from http://www.ivoa.net/xml/VOSITables/v1.0.

Cheers,
	Paul.


-------------- 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/grid/attachments/20180906/177dfbb3/attachment-0001.p7s>


More information about the grid mailing list