RE: [xliff] Inline codes in Change Tracking

["Estreen, Fredrik" <Fredrik.Estreen@lionbridge.com>]

Hi Yves, All,

I think that using references to segment "id"s are a bad practice unless you also disallow segmentation changes for the unit. If the unit is re-segmented or the content re-distributed between existing segments the references will be dangling. In some cases it may be possible to update the referencing data to match the new segmentation but that is not trivial or probably even wanted or possible in some cases.

A definition that "source" mean the whole source of the unit and "target" the whole target of the unit would be safe with respect to segmentation changes. Using <mrk> tags would make sub-unit change tracking of spans safe as well.

I think I raised the danger of having "id" on segments and how it would impact re-segmentation before. In my opinion not having ID's on segments would be better as it would force all implementations to use schemes that are compatible with segmentation changes.

Regards,
Fredrik Estreen

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: den 6 december 2015 21:17
To: 'XLIFF Main List' <xliff@lists.oasis-open.org>
Subject: RE: [xliff] Inline codes in Change Tracking

Hi all,

Another question related to change tracking:

In the example 5.6.6 (http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#d0e15038)

Some revisions are for the source, other for the target. But there is only one segment in that example. How do we indicate a given source or target element when there are several segments?

I assume we can't use the ref attribute since there is no id on <source> or <target>, and the definition for ref clearly requires an ID value.

On the other hand the definition of ref ("Holds a reference to a single instance of an element that has multiple instances within the enclosing element.") doesn't really say what the reference has to be for the element the revisions apply. It's implied in the example for the <note>, but it's just an example. Does that mean I can do <revisions appliesTo='target' ref='seg1'> and assume tools will know these revisions are for the <target> of the segment id=seg1?

Any clarification would be welcome.

Thanks,
-ys

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Sunday, December 6, 2015 1:01 PM
To: 'XLIFF Main List' <xliff@lists.oasis-open.org>
Subject: RE: [xliff] Inline codes in Change Tracking

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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php