RE: Versioning

[Michael Fitzgerald <mike@wyeast.net>]

I offer a few thoughts on versioning.

I prefer the explicit, direct approach, i.e., and attribute/value pair such
as version="1.0". It is succinct and immediate, leaving no question to the
human reader as well as processing application what version you are dealing
with or intend to deal with. Requiring it, as do elements
stylesheet/transform in XSLT, is a good thing I believe. I have never heard
a complaint about it in the XSLT community, though James may have.

Perhaps you are familiar as I am with other versioning techniques. For
example, SOAP 1.1 does its versioning with a namespace URI, that is,
http://schemas.xmlsoap.org/soap/envelope/ with 1.1. (It seems to presuppose
a resource at the other end of the URI, as it does have one there. How
significant this is to versioning I don't know.) Perhaps some think this an
elegant solution, but I don't think it is as clear or immediate as a version
attribute and how do you succinctly increment this? cXML and xCBL do not use
W3C namespaces but associate a versioned DTD with their root elements.
Perhaps this is adequate for a vendor-based vocabulary, but it does not take
into account progressing technology, i.e., they seemed to have ignored W3C
namespaces for the time being. Not good.

My opinions:

1. A required version attribute, at the very least, would be a good thing.
2. I think requiring a namespace URI is a good idea as well, though it may
not be always required.
3. URNs for namespace IDs...namespace rec allows them. I could be convinced
otherwise, but I think they are less confusing than a URL that does not
reference an actual resource.
4. I am intrigued by FPIs, but I don't think we should require them until
they become more formal and receive wider support.

Mike



> -----Original Message-----
> From: James Clark [mailto:jjc@jclark.com]
> Sent: Sunday, February 18, 2001 2:34 AM
> To: TREX Discussion List
> Subject: Versioning
>
>
> The TREX language is going to evolve over time.  This means we need a
> way for TREX patterns to indicate which version of TREX they are using.
> I see the following alternatives:
>
> (a) Put a version in the TREX namespace URI
> (b) Use a version attribute on the root element
>
> Whatever way we do versioning, I think, for robustness, we must require
> the version to be specified. A problem with (b) is that, with TREX as it
> is, it is hard to write a pattern that makes the version attribute
> required on just the document element.
>
> At the moment, TREX does not require the use of a namespace URI for TREX
> patterns; you can say either
>
>   <grammar>...</grammar>
>
> or
>
>   <grammar xmlns="http://www.thaiopensource.com/trex">...</grammar>
>
> So I think if we went with (a), we would have to tighten this and
> require the use of a namespace URI.
>
> A related issue is what happens when there's a mismatch between the
> version of the pattern and the version of the processor.  There are two
> cases here:
>
> (i) The pattern is version 1 and the processor is version 2 (backwards
> compatibility). This seems relatively easy to deal with.
>
> (ii) The pattern is version 2 and the processor is version 1 (forwards
> compatibility).  This is much harder.  One possible answer is that all
> we expect of the processor in this case is that it be able to give an
> error saying that it cannot handle this version. A more ambitious
> approach would be to provide for fallback: specify how a version 1
> processor deals with elements and attributes it does not recognize in
> future versions, and maybe provide ways for the pattern to control how
> fallback happens.
>
> I guess my preference would be:
>
> - put the version in the namespace URI
> - require the use of a namespace URI for TREX elements
> - do not provide any kind of forwards compatibility (ie a version 1
> processor confronted with a version 2 stylesheet would simply tell the
> user to upgrade their processor)
>
> James
>
>