- From: Yves Savourel <ysavourel@translate.com>
- Date: Fri, 22 Dec 2006 11:08:06 -0700
- To: "Jirka Kosek" <jirka@kosek.cz>, "Felix Sasaki" <fsasaki@w3.org>
- Cc: <public-i18n-its@w3.org>
Hi Jirka, all, >> ITSWG: We think that the mechanism described at >> http://www.w3.org/TR/2006/CR-its-20061102/#its-version-attribute is >> sufficient and makes it easier to search for version information (only >> two elements, its:rules or the root element need to be checked for >> *all* ITS markup) than the ancestor approach you are suggesting (with >> that approach you would need to check ancestors for each local ITS >> markup and for rules element). > > Yes, I understand. But with this approach it is not possible to scan ITS > markup in a streaming mode -- for example, on example 10 there is > its:translate before its:version. I don't know whether ability to read > document in a streaming mode is essential requirement for ITS, but > to me it seems strange that you must do look-ahead on the > its:translate attribute to find which version of ITS is used. We didn't see this as an issue because, according the precedence rules, an ITS processor must apply the rules in <its:rules> before it applies the local its:translate. So, from the viewpoint of implementations (at least the one we have so far) having the version in <its:rules>--even if there is local ITS markup before--is not an issue: When we deal with the local its:translate we have already processed <its:rules> and know the version. In other words: We have the version in the first place the ITS processor will look at, regardless of its physical location in the file. As for why not always simply put its:version in the root: I think we avoided this to be less intrusive. If there are no local ITS rules, just one global <its:rules> element, all the ITS markup is self-contained in one element that developers of the host formats can locate where they want (where it has the least impact on the tree for example). Granted, its:version on the root would not be a problem, but it would force the schema to allow it there and it would be two locations to change to add/removing ITS information. Cheers, -yves
Received on Friday, 22 December 2006 18:08:42 UTC