This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2876 - Need to address versioning
Summary: Need to address versioning
Status: CLOSED FIXED
Alias: None
Product: ITS
Classification: Unclassified
Component: ITS tagset (show other bugs)
Version: WorkingDraft
Hardware: PC Windows XP
: P2 normal
Target Milestone: LastCall20May
Assignee: Felix Sasaki
QA Contact: ITS mailing-list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-15 01:33 UTC by Felix Sasaki
Modified: 2006-07-21 17:48 UTC (History)
0 users

See Also:


Attachments

Description Felix Sasaki 2006-02-15 01:33:13 UTC
We need to address versioning of ITS.
Comment 1 Christian Lieske 2006-02-15 07:37:19 UTC
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
Comment 2 Felix Sasaki 2006-02-15 07:39:18 UTC
(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 ....
Comment 3 Felix Sasaki 2006-02-17 04:15:20 UTC
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.
Comment 4 Yves Savourel 2006-02-17 05:15:00 UTC
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). 

Comment 5 Felix Sasaki 2006-02-17 05:19:09 UTC
(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.
Comment 6 Yves Savourel 2006-03-04 05:34:13 UTC
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.
Comment 7 Yves Savourel 2006-03-17 20:25:59 UTC
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)?
Comment 8 Yves Savourel 2006-03-29 17:14:36 UTC
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.
Comment 9 Felix Sasaki 2006-04-11 07:36:05 UTC
(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.
Comment 10 Felix Sasaki 2006-04-20 08:12:59 UTC
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