Re: action-221 summary of overriding discussion

One correction to the below:

"The question is maybe: do you need XPath to specify that in XLIFF, and
would it be OK for this information to be orthogonal? If not, there is no
need to influence selection precedence."

This should have been "If this is the case, there is no need to influence
selection precedence."

Also, apologies for repeating the "orthogonal proposal" so often :)

Best,

Felix

2012/9/21 Felix Sasaki <fsasaki@w3.org>

> Hi Yves, Dave,
>
> thanks for your feedback. We are probably stuck, since I still won't agree
> with partial overriding and also not with combining data categories. A few
> comments below.
>
> 2012/9/21 Yves Savourel <ysavourel@enlaso.com>
>
>> Hi Felix, all,
>>
>> The solution of some tool information being declared outside the usual
>> selector mechanism may work for one set of instances of a given data
>> category, but not several. For example:
>>
>> In an XLIFF document I'd like to use the its:mtConfidenceScore attribute
>> for each <m:match> element that holds a translation candidate for an entry
>> (This is a likely real-life case, not just a random example). You can have
>> multiple matches per entry, and they are very likely to be from different
>> engines. Having a document-level tool information does not work. In this
>> case we do need to have the tool information per entry.
>>
>
> Tool information is really orthogonal to data categories IMO - for the
> content itself (like in MT) and for ITS annotations you may want to
> express: who produced this? For ITS annotations, this is urgently needed
> for disambiguation. But actually each data category can be produced by a
> tool, and it would be useful to capture that information in an orthogonal
> manner IMO.
>
> The question is maybe: do you need XPath to specify that in XLIFF, and
> would it be OK for this information to be orthogonal? If not, there is no
> need to influence selection precedence.
>
>
>>
>>
>> Looking again at the "partial override" solution I don't think pointers
>> are a problem. They just tell where to get the information to apply to the
>> node, as far as overriding goes it's no different than setting directly the
>> information.
>>
>
>
> We can continue the discussion on partial override, but I would suggest to
> stop it. I can "promise" - as said before - that I would (formally) object
> against this, and this is very unlikely to change. The backwards
> compatibility, the ambiguity wrt the intention of the data category author
> (e.g. "is the 'alert' type of a locnote intended or not?"), and esp. the
> constraints about pieces of information are an issue. Such constraints are
> a different beast than pointers or standoff markup. With constraints I mean
> what we say e.g. with loc quality issues: "exactly one of the following,
> none or one of the following" or in other areas we say "optionally". With
> these mutually exclusive and other options the complexity rises: if there
> are two mutually exclusive items, one at a node and one inherited, which
> one takes precedence? Sure there can be answers, but these are data
> category specific and much more complex than "if a value doesn't exist on a
> node take the inherited one".
>
> With partial inheritance I would need to re-engineer my implementation,
> and very likely I wouldn't do that but rather drop the implementation
> completely. Even if that is no theoretical issue as you had mentioned in a
> mail before, I think it is a valid concern.
>
> So my proposal to move forward would be to re-iterate the orthogonal
> character of tool information: it seems tool information is really the only
> case there the partial overriding or the data category combination (see
> comment below) have a strong case.
>
> Wrt to Dave's proposal from
>
> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Sep/0124.html
>
> [
>
> However, if we relax this assumption in a controlled way we can simply
> avoid partial override by designing certain data categories to be used in
> _combination_ (the subtle difference to a single data category
> being'compound'). In this event we can then either just live with the fact
> that there may be one or to data categories that may impart conformance
> individually even though they are not useful by themselves, or we add them
> as a specific exclusion to the single-data-category-for-conformance rules.
> ]
>
> In my experience, if you introduce a feature once (combination of data
> categories), people will develop use case over time to have it in other
> areas to. So that will influence conformance a lot and in essence destroy a
> basic design principle from ITS 1.0: "It adopts the use of data categories
> to define *discrete* units of functionality".
>
> So we are probably stuck.
>
> My proposal to move forward would be to see if we agree on the orthogonal
> character of the tool information and define it for all data categories, as
> a separate piece of information and with the effect of a separate
> conformance clause, but with no effect on selection mechanisms. If we have
> that agreement we can explore how to accomodate Yves' requirement to attach
> the information not to a whole document, but to parts of it. Maybe even
> XPath is not needed for that. At least that is what Declan and Tadej said
> for mtConfidence and disambiguation on the call.
>
> Best,
>
> Felix
>
>
>
>> The case of the stand-off markup is specific (so far) to Localization
>> Quality Issue. I haven't thought yet about what that implies for the
>> "partial override" but it's likely that there are ways to specify what is
>> done in those cases.
>> The bottom line is that all those local/global/standoff attributes
>> specify information and are applies in a given order: we've got to be able
>> to know if the information ABC exists or not when we apply the next rule,
>> and therefore be able to keep the current value or override it depending on
>> whether the next rule re-define that information or not.
>>
>> Cheers,
>> -ys
>>
>>
>>
>>
>>
>
>
> --
> Felix Sasaki
> DFKI / W3C Fellow
>
>


-- 
Felix Sasaki
DFKI / W3C Fellow