Inline attributes and canCopy

[Ryan King <ryanki@microsoft.com>]

Hi TC, we’ve run into a dilemma and require some expert guidance. The XLIFF 2.0 spec says this about Id:

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

o    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.

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

So, when an inline element is copied, I might get this example from the spec:

 

<unit id="1">

<segment>

  <source>Äter <pc id="1">katter möss</pc>?</source>

  <target>Do <pc id="1">cats</pc> eat <pc id="2" copyOf="1">mice</pc>?

  </target>

</segment>

</unit>

 

In order for this to meet the above constraint, the intended meaning is probably something like:

 

·         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. *Copies of inline elements are not considered to be corresponding to the original elements enclosed within the sibling <source> element and do not need to have the same id.*

 

And if that is true, when we validate the constraint to make sure the *original* source and target inline element ids match, how do we know which one is the original one if copyOf is not required and they can be reordered? If I just rely on making sure at least one of the Ids match regardless of position, what happens if I deleted the original elements in <target> and add back in two new ones? Do I have to make sure at least one of the elements has an id that matches? It seems like a lot of processing just satisfy the constraint.

 

What is the logical reason for this constraint?

 

Thanks,

Ryan