Re: [All] spec edits, please have a look

Hi Felix,

My concern is that if we have itstool defined both as an attribute 
locally in the document and then as an attribute in global rules, we 
have to define more complex overide semantics. I haven't had a chance to 
think up a concrete example, but I have the feeling that may interact 
with data category overrides in tricky ways.

So if we include support for annotating its-rules I would suggest that 
we make these two modes of itstool annotation mutually exclusive, i.e.
replace
"The attribute applies to the content of the element where it is 
declared (including its children elements) and to the attributes of that 
element."

with
"The toolsRef attribute can be defined in a document in exactly one of 
the following ways:
1) As an attribute to an element of the document. In this case the 
attribute applies to the content of the element where it is declared 
(including its children elements) and to the attributes of that element.
2) As an attribute to a rules element. In this case the attribute 
applies the IRI as a toolsRef annotation only to the content of the 
elements (including its children elements) selected by a rule for the 
data category associated with that IRI, and to the selected attributes 
of those elements."

This would avoid any complex override interactions, and suit the points 
you have below . Thoughts? If this makes sense I can come up with an 
example.

On these points - I have some, hopefully clarifying, comments.

> - what to do if you cannot put the toolsRef locally, because the 
> format does not allow to use toolsRef?
This would be no more likely than for any data category, so are you 
specifically considering occasion where no ITS annotation is possible 
and we are just specifying global rules in an external file linked in a 
platform-specific mechanism? In this case yes we'd need a way to specify 
itstool, but see below with respect to global rules.

>
> - and: if an implementation implements a data category only globally, 
> why should it need to "look" for toolsRef locally?

The answer could be 'because the spec says so', as the decision to 
implement itstool is mostly independent of the choices to implement data 
categories. The exceptions are the confidence score options for 
mtconfidence, diambig and terminology where the link is mandated. But 
here it would seem unlikely that anyone would implement _only_ the 
global options, since they typically get applied fragment by fragment. 
The global options are only for rdf pointer in disambig and to enable 
annotation of attribute text, e.g. example 87/88 for mtconfidence.

> - if you want to apply information to several documents, global rules 
> are handy. But you would then not change each document to specifiy 
> "this tool has set the xyz attribute", but it would be handy to 
> provide the information as part of the global rule.
>
Yes, this is convenient, though again not necessarily a major use case. 
sometime the binding of document-to-tool won't  be the same as 
document-to-rule, i.e. the same rule (especially pointers) may apply, 
but the tools may differ in some cases.

cheers,
Dave