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

Hi Yves, Dave, all,

I would come up with even a third proposal: just say that toolsRef 
cannot be used globally. The reason is that the data categories that 
mainly use it will use it to accompaign local markup. So if a tool adds 
local markup it will also be able to add a toolsRef attribute.

This approach would also mean we don't have to add a functionality in 
the last minute, which isn't tested at all and would have the danger to 
delay our "last call" stage.

Best,

Felix

Am 26.11.12 05:09, schrieb Yves Savourel:
>
> 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
>
>