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

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

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: david.filip@ul.ie

On Sun, Aug 18, 2013 at 5:57 AM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi David, all,

I looked at the latest editor's draft.
I'm seeing this:

> For a <unit> element to be ready for Merging it is
> REQUIRED that all its <segment> children with

> translate set to yes have the approved attribute set to yes.

This is not an hint anymore. In a sense it's better because it's a feature all tools need to implement. But with the default set to
'no' and the constraints with the state attributes still in place it is currently also worst.

Currently you are forcing tools to change this flag to allow merging,

That is right, as XLIFF is a roundtrip exchange format, I believe something should be done to the file in all valid use cases before it makes sense to merge back 

and that may also require a change of the state values.

It may require to change state if the poeple set their custom workflow so that it is required and it is absolutely up to them

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.

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. 

or why a segment set to 'final' must always be merged).

The reformulated Constraint allows you to say that a unit is not ready for merging, yet it does not allow and it would not make any sense to say that the merge must be performed. We are merely specifying a requirement for merging. Whether the merging occurs or not is up to the Merger.

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. 

So, to avoid having to deal with this again in the next review cycle, here is possible solution:

-- rename 'approved' to 'canMerge'

-- set the default of canMerge to 'yes'

-- remove the two constraints that link canMerge to state.

-- Make clearer what mergers must do with canMerge. Right now 'approved' has no PR and while there is a constraint in the unit
section that sets some requirement about how to *indicate* a unit is ready for merging, it doesn't explicitly says what merger must
do if that requirement is not met:

I do not think that we can or should make any positive statements on what Mergers must do 

it will bring interoperability issues.
I would add a PR in the canMerge section saying a merger must not merge a segment with canMerge='no'.

This seems plausible and I will add this PR 

and I would drop the
constraints in the unit section.

I think that the Constraint at the unit level makes sense because  it interprets the situations where not all segments within a unit have approved set to the same value.

Then we'll have an interoperable flag that tools can use to prevent merging (which is what you want) but this won't force any force
tools to change state to merge (which is what I want).

Another remark: having approved/canMerge is <file>, <group> and <unit> is not especially useful: it forces parsers to keep track of
it across the document and can lead to weird cases where you have an approve/canMerge='yes' in unit but one of its segments set to
'no' (making the current constraint in unit strange: one can have a non-mergeable unit that has its canMerge attribute set to yes).
And if try to correct this by adding yet another constraint in unit that says "if one segment has approved='no' then unit must have
approved='no'", then you have to do it for group, and file as well, and this is becoming not implementable.

We of course do not want this to be circular, but it is not in the current solution

The flag is inherited across structural levels

For me the flag should be either required or inherited. I made it inherited becuase Ryan suggested to have it inheritable and no one objected. I think it is convenient for writers, although admittedly requires some parsing erffort

The above is the same weird as a unit with srdDir=LTR that has all enclosed source elements with dir=RTL

So it is weird but you don't need to do it in either case, it is just possible.

The unit with approved set to "yes" whose one segment has approved set to "no" simply is NOT ready for merging and must not be merged.

If we renamed the approved to canMerge it would appear weird I agree but it is neither circular nor inconsistent.

All that said I see that the above set of proposals if accepted together is a viable implementable option for the pair of attributes, so that I will try to make a branch with your proposal after I have implemented all other necessary changes, so that the TC has two options for moving forward tomorrow

Cheers

dF

Cheers,
-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