RE: [xliff] Inline IDs in <source>/<target> in mtc and ctr modules

[Yves Savourel <ysavourel@enlaso.com>]

Hi Soroush, all,


> I think as far as the "ref" attribute is pointing to a concrete 
> core span (segment[@id="m1"] in this case) and since both "source" elements in 
> "match" and "segment" contain identical text, mapping for inline elements should 
> not cause any problem. Isn't it the case for Translate Candidates module?

Alas, I don't think the specification has any provision for any of this.

The definition for id in pc, sc, and ph says:

[[
When used in <segment>, <ignorable>, <mrk>, <sm>, <pc>, <sc>, <ec>, or <ph> elements:

- The inline elements enclosed by a <target> element MUST use the duplicate id values of their corresponding inline elements
enclosed within the sibling <source> element if and only if those corresponding elements exist.

- Except for the above exception, the value MUST be unique among all of the above within the enclosing <unit> element.
]]

The last bullet is pretty clear: except for the case of bullet one, the value of an id must be unique within the enclosing unit. In
the example the enclosing unit has 3 id='1' and the bullet one exception may apply only to the one in target.

We didn't have any example of the Translation Candidate with inline codes unfortunately, so none of the validation tools run into
such case. In a sense that may also be a chance, because no-where we have an official example showing one cannot have such
duplicates.

Both Okapi and XMarker validator do not give an error for the example. I don't know about MS' XLIFF-OM (can't run it with
VS-Express, which is the only VS I can access during the holidays). But at least 2 out of 3, (and maybe 3 out of 3 validators),
interpreted the spec as allowing duplicates when in the match elements. That may give us an opening to explain the problem in the
2.0 spec as a case forgotten, and provide a clarification in 2.1. 

Cheers,
-ys