Didn't we already discuss metadata like an attribute "version" (along the lines 
of XSL or XML for example)? Of course deciding on how to represent versioning 
information is only one part of the stories. Others may be:

1. What's the version identifier we want to use in the last call?
2. Will we have minor and major releases? If so: What merits a major release?
3. Do we have make explicit statements about backwards compatibility?

Best regards,
Christian

(In reply to comment #1)
> Didn't we already discuss metadata like an attribute "version" (along the lines 
> of XSL or XML for example)? Of course deciding on how to represent versioning 
> information is only one part of the stories. Others may be:
> 
> 1. What's the version identifier we want to use in the last call?
> 2. Will we have minor and major releases? If so: What merits a major release?
> 3. Do we have make explicit statements about backwards compatibility?
> 
> Best regards,
> Christian

So far we are doing none of these. We have to tackle this before May 20 though ....

Per http://www.w3.org/2005/05/tr-versions , versioning reflects also in the URI
of the document. This syntax is recommended (see sec. 3.2 of tr-versions):
   1. /TR/<shortname>: Latest <Name> Recommendation
   2. /TR/<shortnameN>: Latest <Name> N version
e.g.
   1. /TR/MathML/ : Latest MathML Recommendation
   2. /TR/MathML2/ : Latest MathML 2 version
Since we don't use /TR/ITS1 yet, we might think of doing so.

I'm wondering about using a version number in the namespace URI. There 
certainly a few arguments against it.

There is an interesting post on that topic here:
http://lists.oasis-open.org/archives/xliff-comment/200602/msg00001.html

One example it gives is XSLT which does not use version in its namespace URI, 
but an attribute (http://www.w3.org/TR/xslt20/#stylesheet-element). 

(In reply to comment #4)
> I'm wondering about using a version number in the namespace URI. There 
> certainly a few arguments against it.
> 
> There is an interesting post on that topic here:
> http://lists.oasis-open.org/archives/xliff-comment/200602/msg00001.html
> 
> One example it gives is XSLT which does not use version in its namespace URI, 
> but an attribute (http://www.w3.org/TR/xslt20/#stylesheet-element). 
> 
> 

Sorry for not making this clear, but what I meant  in comment
http://www.w3.org/Bugs/Public/show_bug.cgi?id=2876#c3 was not the namespace URI,
but the URI of the specification, e.g
/TR/ITS1 (version 1)
/TR/ITS2 (version 2)
/TR/ITS (latest version)
The namespace URI which we define at
http://www.w3.org/TR/2006/WD-its-20060222/#d2e576 should be the same for all of
these.

There are two main ways to add version information to ITS:

#1 As a version number in the ITS namespace URI. This technique has several 
drawbacks and is usually not used in other W3C markups. There are a few 
exceptions, for example: SMIL.

#2 As a version attribute. This method seems more efficient and is usually the 
one used at the W3C, for example: SVG and XSLT.

In the case of ITS there is one issue that creates some complications. ITS 
elements can be scattered in a set of documents, and some ITS constructs are 
made only of attributes. In other words, a processor could possibly have to 
handle ITS blocks that have different versions.

For example, an ITS processor could find ITS markup:
- in a schema file
- in a standalone ITS document
- in <documentRules> elements within a document
- in elements of the host documents (ITS local attributes)

The first question is: Shall ITS allow this?

I assume do have to, since someone may have control over the document 
instances without having control over the schema or an external documentRules 
(and conversely).

I would propose to use an its:version attribute declared in the root element 
of the document where the ITS namespace is used. This would give us for 
example, for an host document:

<myDoc xmlns="myDocURI"
 xmlns:its="http://www.w3.org/2005/11/its"
 its:version="1.0">
...
 <its:documentRules>
 ...

And (for standalone ITS documenrRules):

<its:documentRules
 xmlns:its="http://www.w3.org/2005/11/its"
 its:version="1.0">
...

We would have the technical possibility to have one version attribute in the 
root and another is a documentRules. I'm not sure how to prevent this (and 
validate the prevention).

The other question is that we may have conflicts between the versions if we 
change how precedence are handled.

Comments from Martin about Versionning:
(http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0279.html)

Before looking at how to mark versions, and how different versions may work together, I think it's important to look at potential extensibility points:

What are the things most likely to be added or changed in the future? How can the current stuff be defined so that e.g. future additions create minimal impact (e.g. additions are just ignored or have some default behavior)?

Another of the discussion topics for this week is this issue: ITS versioning.

The current proposal is to have an its:version attribute that one would put in the root element of the document, so it covers both the version of the <its:rules> element(s) inside the document and any ITS markup used locally.

I'm not sure such attribute would need to be required in the first version, since it because relevant only when if/when a new version would be done.

See also Martin's note about Versioning in the bug thread.

(In reply to comment #8)
> Another of the discussion topics for this week is this issue: ITS versioning.
> 
> The current proposal is to have an its:version attribute that one would put in
> the root element of the document, so it covers both the version of the
> <its:rules> element(s) inside the document and any ITS markup used locally.
> 
> I'm not sure such attribute would need to be required in the first version,
> since it because relevant only when if/when a new version would be done.
> 
> See also Martin's note about Versioning in the bug thread.
> 

I made this comment before, but just to keep track of it: wee need to address the requirements for versioning mentioned at
http://www.w3.org/2005/05/tr-versions
not that these requirements are about the URI of the document, and *not* the namespace URI.

resolved at http://www.w3.org/2006/04/19-i18nits-regular-call-minutes.html:
summary: the its:version attribute is mandatory at the rules element, if there is no rules element, it goes at the root element of the instance. If there are both it is an error if they have different versions.
... each file can have a different version. E.g.: if there are external rules imported via xlink:href, they could have a different version
... if we change anything related to precedence order, we are in big trouble
TODO: http://www.w3.org/2006/04/19-i18nits-minutes.html#action02 felix to write a paragraph about the version attribute
bug closed