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

Hi Dave, Felix, all,

 

The changes Dave proposes seem a good way to define how toolsRef is used.

 

for the second part I would maybe try to make it simpler:

 

2) As an attribute in a rule element. In this case the attribute applies to the content of the selected nodes: the value of the attribute if the node is an attribute, the content of the element (including its children elements) and to the attributes of that element if the node is an element.

 

Maybe we could even indicate that the inheritance for the given the data category does not applies to toolsRef.

(or something like that).

 

-yves

 

 

From: Dave Lewis [mailto:dave.lewis@cs.tcd.ie] 
Sent: Sunday, November 25, 2012 7:18 PM
To: public-multilingualweb-lt@w3.org
Subject: 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