W3C home > Mailing lists > Public > public-i18n-its@w3.org > January to March 2006

[Bug 2876] Need to address versioning

From: <bugzilla@wiggum.w3.org>
Date: Sat, 04 Mar 2006 05:34:14 +0000
To: public-i18n-its@w3.org
Cc:
Message-Id: <E1FFPPC-0007gN-CI@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=2876





------- Additional Comments From ysavourel@translate.com  2006-03-04 05:34 -------
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.
Received on Saturday, 4 March 2006 05:34:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:06 UTC