Versioning

[James Clark <jjc@jclark.com>]

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