RE: [xliff] Inline codes in Change Tracking

[Yves Savourel <ysavourel@enlaso.com>]

To complement my initial questions: here is an XLIFF file.
Is it a valid one or not?

Thanks,
-yves


-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Saturday, December 5, 2015 12:54 PM
To: XLIFF Main List <xliff@lists.oasis-open.org>
Subject: [xliff] Inline codes in Change Tracking

Hi,

I'm looking at how to represent inline codes in the <item> element of the Change Tracking module (for 2.1) and I'd like to make sure
it doesn't break the 2.0 constraints. I'd like to double-check my interpretation.

The simplest way to store an old version of the translation of a segment is to copy it in the CTR's <item> element:

<unit id='1'>
 <ctr:changeTrack>
  <ctr:revisions appliesTo="segment" ref="s1">
   <ctr:revision>
    <ctr:item property="content">This is a <pc id='1'>sample</pc></ctr:item>
   </ctr:revision>
  </ctr:revisions>
 </ctr:changeTrack>
 <segment id='s1'>
  <source>C'est un <pc id='1'>exemple</pc></source>
  <target> This is an <pc id='1'>example</pc></target>  </segment> </unit>

The potential issue there is the <pc>'s ID.

The specification says the following for the attribute id:

[[
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.
]]

In the representation above we get three <pc id='1'> in the <unit>: The one in <source>, the one in <target> and one in <item>. It
seems to me that, according the constraint, the ID of <pc id='1'> in <item> is not valid since it is duplicated within <unit> and
it's not in a <target>.

1) Is my assumption (it's not valid) correct?

2) If so, how did manage to get away with it for <match> (The Ids in the <source> of <match> can be the same no?). 

Thanks,
-yves

Attachment: test-file.xlf
Description: Binary data