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

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

>> I strongly believe merging must be allowed regardless of the value of state.
>> (You still have not given any rational as why one shouldn't be allowed to merge
>> translations in a 'initial' state, ...
>
> As i said above IMHO it does not make sense to merge with state
> initial because XLIFF 2.0 is clearly intended for roundtrip exchange
> scenarios and IMHO it does not make sense in any valid use case
> [and I still do not think that testing is a valid use case] to merge
> back without any changes to the segments.

Allowing to merge translations that are in the 'initial' state is not breaking any principle of doing a round-trip.

I'm also giving you a real *production* use case where we do round-trip with untouched XLIFF documents to make sure they merge
properly (this is not debugging a filter during development).

Forbidding an action because of a presumption what make sense or not to you is not good thing to do when that action has no bearing
on the XLIFF document: just let people merge untouched files/translations set to 'initial': it doesn't bother anyone.



>> We must not force tools to fit certain workflow when 
>> it can be avoided.
>
> I do not think that we are forcing people into any particular 
> workflows, except making at least some minimal changes to 
> the XLIFF file before it is fit for merging.

The except part is definitively forcing a given workflow.



> The only illegal state for merging is initial and if the
> state is not explicitly set the default for state is (since the printouit 
> a few days ago) "translated" in the scope of an approved "yes". 
> So people do not need to use state if they don't feel so
> Still the defined relationship allows to use them sensibly together.

This is getting worst and worst: Now a tool can implicitly modify the state values by modifying another attribute that may be
anywhere in a parent element. You are begging for chaos.

And we have constraints for state like "The OPTIONAL attribute state MUST NOT be set to final if and only if the OPTIONAL attribute
approved on the same <segment> element is set to no.", where we do not specify what to do when approved is inherited.
If you drive the values of state with canMerge/approved then it needs to be required on all segments (and then having them on unit,
group and file makes no sense).

I assume you also realize that now a segment with translate='no' may have its state seen as 'translated' by default.

David, please, we really need to just disconnect completely state and canMerge, set the default of the first to 'initial' and the
second to 'yes'. You will have a merge indicator in place and it won't provoke any disruption. Those two attributes have no reasons
whatsoever to be connected.

In my opinion, with the specification as it is today you are heading straight for substantial changes in the next review round.

Regards,
-yves