Re: Versioning

[Eric van der Vlist <vdv@dyomedea.com>]

James Clark wrote:
> 
> 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

Couldn't we do... both ?

Changing a namespace is breaking any chance of forward compatibility
since a processor cannot guess when a new namespace is still TREX
(except if we defined a kind of pattern on the way namespaces URIs are
being defined which would, IMHO, be rather messy).

We could keep the same namespace and use a version attribute for minor
changes for which forward compatibility might be achievable and change
the namespace URI for each major revision when we can consider that the
meaning of the elements have been significantly changed.

> 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.

A way to achieve this could be to use a different namespace for new and
updated elements. The processor would then just ignore the namespaces he
doesn't support...

I wonder if this is worth the pain, though.

> 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)

The use of a version in the namespace URI is coherent with not having
any forward compatibility.

I would prefer to add a version attribute that we could use for minor
changes.

A processor could then be strict if there is a match between its version
and the version of the grammar, and send a warning and ignore unknown
elements and attributes (either silently or sending warnings) when the
version of the grammar is higher than its own version.

The same version attributes could be used to deprecate elements and
attributes.

And when the vocabulary becomes different enough, we change the
namespace URI.

Eric
 
> James

-- 
See you in Austin (Knowledge Technologies 2001)
              http://www.gca.org/attend/2001_conferences/kt_2001/mon.htm
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------