RE: [xliff] Call for Dissent was Re: [xliff] csprd01 comments 11 and 41

[Yves Savourel <ysavourel@enlaso.com>]

Hi David,

> I said in a previous e-mail that state of segments 
> and readiness for merging are a different thing 
> because of relatively new use cases such as 
> crowdsourcing and raw machine translation publishing
> .. And this is my bottom line.

The approved attribute exits in 1.2, so it's not new. But I see that we have changed its meaning.

In 1.2 the definition clearly indicates a relationship with the status of the translation: "Approved - Indicates whether a
translation is final or has passed its final review."

While in the current 2.0 editor's draft we have: "Approved - indicates whether the holding <segment> element contains a translation
suitable to be used when Merging the XLIFF Document back to the original format."

The first thing I propose then is to rename that attribute to avoid any confusion with the 1.2 approved attribute. For example to
something like 'canMerge'.


> It is not true that there is no relationship between 
> state and approved in the current solution
> But the relationship is minimized to cater for a 
> variety of use cases.
> Approved=yes is consistent with all states except for initial

The second thing I propose is to drop those new constraints between approved/canMerge and state. There is little benefits to try to
enforce some loose relationships. A tool may want to merge the initial version of the text, even if it's the same as the source
(which by the way state=initial does not imply) for example when testing the round-trip for a given filter on a given document.


> We suggest that approved is a merging readiness hint,
> but it is up to the Merger to decide if they wait for
> state=final, or if they are happy with state=translate 
> for interim publishing of support content or crowdsourced 
> version of a wiki article etc.
> I do not think that this sort of freedom is bad, in fact 
> this is exactly what I intended with the proposed solution.

If approved/canMerge is just a hint tools can disregard both in modifying or reading the document, then:

a) I propose to say so in its definition. Maybe something like: "Approved - provides a hint indicating whether the holding <segment>
element contains a translation suitable to be used when Merging the XLIFF Document back to the original format."

b) and I propose to make it optional (we are just asking for trouble to force tools to set a value for something they don't have to
use).

c) and I propose to remove the third constraint in <unit> that talks about approved: it's not really a constraint and it doesn't
bring any new information in the specification.


Now for the "new" scenarios you are mentioning: the approved/canMerge attribute is just reflecting a decision rather than storing
the true information.
The true metadata we should be carrying for interoperability is: a) the state of the translation and b) its provenance. Currently
XLIFF 2.0 has no provenance mechanism in the core. There are some level of provenance information in the Change Tracking module, but
I don't think it would cover information about the type of translation/change performed.

The more I look at it the more I think approved/canMerge is a dangerous attribute: it is confusing, it doesn't carry a true
information about the data but an hint about a decision driven by other information, it may be ignored but it's required, it has a
different meaning as in 1.2 but it has the same name, etc.

I think approved should be dropped altogether and (if needed) have a more useful provenance module in 2.1.

Cheers,
-yves