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

["Dr. David Filip" <David.Filip@ul.ie>]

Yves, everyone,

it seems to be clear that this call for dissent failed. Our positions are irreconcilable and no one else engages in the discussion.

I will finalize the solution with approved and state both in place and will ask Bryan to start the meeting on August 20 with a ballot on this solution.

It can be either yes or no ballot for the solution currently in the wd02 as it will be finalized by the meeting time with the recursive approved flag.

I will be taking into account the improvement suggestions from the first part of your e-mail, as indicated inline below.

Or it can be a ballot between two options, in that case I'd like to ask you to specify the other option, is it just killing the approved and no other changes?

It is a little bit confusing becuase in the first part you are making suggestions for the two attributes solution, while you conclude with the proposal to simply kill the flag..

The other problem is that we cannot make resegmentation PRs without this being resolved. Since I did not hear back from Fredrik or you re those, I will try to devise some resegmentation PRs on the assumption that both attributes are in place, simplifying them should not be a big deal in case TC goes for killing approved.

Please note that I am NOT moving for an electronic ballot since this would not resolve in time for the meeting.

Few more short answers inline

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

mailto: david.filip@ul.ie

On Mon, Aug 12, 2013 at 4:32 AM, Yves Savourel <ysavourel@enlaso.com> wrote:

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'.

I am not in principle against renaming the flag but do not see much benefit in doing so either. 

> 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.

I do not think that testing a filter is a use case that the spec should have in mind. You can do anything while testing and we won't devise PRs saying that you can do anything to allow for testing

 

> 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."

I will implement this 

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).

I will make it optional because it will be recursively inherited with the default "no" on file 

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.

I will try and reformulate it so that it is less offensive.

However since the unit is the lowest level  invariable structural element, I see a value in explicitly saying that it is considered (not translated - as this caused confusion but)  ready for merging back, once all child segments are approved. Not sure now whether it is a PR or Constraint. Maybe it is a PR as it indicates readyness for a predefined process step.

Now for the "new" scenarios you are mentioning: the approved/canMerge attribute is just reflecting a decision rather than storing
the true information.

I do not see how this is not true data

In one representative scenario, the corporate  Extractor/Merger is looking for approved yes to see whether they can merge back.

The service provider has the onus to set the flag, but they are free to use the state freely for controlling their internal process, as the only illegal combinations are initial/yes and final/no.

If you are forcing the service provider to set the state to final to indicate readiness for merging you are overloading the state and preventing the usage of state for tracking the true translation status.

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.

I agree that a Provenance module would be a useful one for a 2.x version. CNGL is interested in that and will actively participate. I do not see however, how this is relevant to killing the flag 

Cheers,
-yves