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

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all,

I've looked at the latest PDF (which seems to have been updated since it's now dated Aug-20) 
https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-20/xliff-core.pdf


We have in the unit constraints:
[[
A <unit> element is considered to be ready for Merging when all its <segment> children with translate set to yes have the approved
attribute set to yes.
]]

That's is not really a constraint: there is no explicit indication on what the merger is suppose to do. Does it mean a merger must
not/should not/may not use the translations if they do not have approved='yes'? If there is no requirements it should not be listed
in Constraints.


Then we have the Constraints in state:
[[
- The optional attribute state MUST NOT be set to final if and only if the required attribute approved on the same <segment> element
is set to no.

- The optional attribute state MUST NOT be set to initial if and only if the required attribute approved on the same <segment>
element is set to yes.
]]

a) The notion of optional vs required here is irrelevant here since we have default values for both attributes (BTW: why do we have
a default for a required attribute? It will never be used).

b) There is also no need for "if and only if" At the very least the constraint should be "the attribute state MUST NOT be set to
final if the attribute approved on the same <segment> is set to no".

c) We also have no corresponding constraint in the section for approved.

d) The second constraint is (hopefully) incorrect: we can't have state='final' also when approved='yes'? so we can never have
state='final'? Obviously you meant "MUST" instead of "MUST NOT" here.

e) Based on those (corrected) two constraints: a merger can look only at state: if it's 'final' it knows for sure approved must be
'yes' and if it's not 'final' it knows for sure approved must be 'no'.

I don't need to make my case further: approved is completely redundant: let's get rid of it.


> Yet the above seems simple and
> interoperable enough to me..

Why forcing tools to write out two attributes that provides implicitly the same information?

The bottom line of all this is that:

1) The attribute approved implies a segment "is ready to be merged" when state='final', so it's a redundant data.

2) providing explicitly the information that a segment is ready to be merged is useless since tools do whatever they want anyway. If
they want to base their merging on information about the status of the translation they should look at state.

Cheers,
-yves