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

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

> 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 first part is the least that IMO needs to be done.
But my conclusion is still the same: 2.0 'approved' is a cause of confusion and IMO not really useful, so I'd rather see it gone.



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

You do not see much benefit in having the name of an attribute reflecting what it represents?
This 2.0 approved represents something different from the 1.2 approved: the text can be merges vs the text is final or has passed
its final review.
I think using a name related to the new meaning would certainly help in clearing up the confusion.



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

Testing if a set of files can do a round-trip is something many LSPs do often in production. But that's just one example. My point
here is simply: why put a constraint on the state value for a 'canMerge' indicator? Why forbid a merger to merge the content in its
'initial' state?



> You can do anything while testing 
> and we won't devise PRs saying that you can do anything to 
> allow for testing.

That is one of the main problems of 2.0: too many PRs. We are defining a format not a process. And we should try to avoid constraint
that force a specific workflow.
 
In addition, note that this 2.0 approved/canMerge is just a hint, so I'm not sure how relevant a PR can be on a hint: you can always
bypass it anyway.



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

I didn't say it was offensive, just useless :)
But importantly: it is not formulated as a PR or constraints, there is no explicit thing that can or cannot be done for the tool
based on that paragraph.



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

That's a scenario you didn't described before. My comment was about the crowdsourcing/raw MT cases you mentioned. In those cases I
was arguing that the information that was really important was the state and the provenance, so the merge can take a decision.

In you new scenario: I guess a canMerge attribute that carries a temporary hint about whether the content can be used or not for
merging could be useful. It seems to be a custom workflow though. And I it still should not be linked to the state values. You are
forcing the tool using canMerge to set the state to something other than 'initial'.

Cheers,
-yves