RE: Reply on comments on ITS tagset draft

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