2876 2006-02-15 01:33:13 +0000 Need to address versioning 2006-07-21 17:48:51 +0000 1 1 1 Unclassified ITS ITS tagset WorkingDraft PC Windows XP CLOSED FIXED P2 normal LastCall20May 1 fsasaki fsasaki public-i18n-its oldest_to_newest 8262 0 fsasaki 2006-02-15 01:33:13 +0000 We need to address versioning of ITS. 8263 1 christian.lieske 2006-02-15 07:37:19 +0000 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 8264 2 fsasaki 2006-02-15 07:39:18 +0000 (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 .... 8300 3 fsasaki 2006-02-17 04:15:20 +0000 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. 8303 4 ysavourel 2006-02-17 05:15:00 +0000 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). 8304 5 fsasaki 2006-02-17 05:19:09 +0000 (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. 8546 6 ysavourel 2006-03-04 05:34:13 +0000 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. 8774 7 ysavourel 2006-03-17 20:25:59 +0000 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)? 8947 8 ysavourel 2006-03-29 17:14:36 +0000 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. 9133 9 fsasaki 2006-04-11 07:36:05 +0000 (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. 9334 10 fsasaki 2006-04-20 08:12:59 +0000 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