Re: action-221 summary of overriding discussion

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