Thanks, Yves
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:
On Tue, Aug 20, 2013 at 6:27 AM, Yves Savourel <> wrote:
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.
It depends on your definition of roundtrip
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.
It forces a minimal roundtrip but gives no specifics at all
> 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.
I see that having the flag recursively inherited was not such a good idea after all. I hope that Ryan agrees and I am going to kill the inheritance in the spec right now..
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.
If the TC agrees to it I have no problem with implementing it, but then we will have done the full circle admittedly with some minor clarifications.
In my opinion, with the specification as it is today you are heading straight for substantial changes in the next review round.
I of course do not want to make material changes in the second round that's why the spec should have a TC approved solution and that's what we've planned to achieve today.
Cheers
dF
Regards,
-yves
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
