OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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, and that may also require a change of the state values. 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, or why a segment set to 'final' must always be merged).
We must not force tools to fit certain workflow when it can be avoided.

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: 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'. and I would drop the
constraints in the unit section.

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]