RE: [xliff] Inline codes in Change Tracking

[Yves Savourel <ysavourel@enlaso.com>]

Hi Fredrik, all,

Good point indeed on the danger of id and segments.

So, the idea is then to use appliesTo="source" or "target" (and property="content") and for those special cases store the changes
ignoring the segments.

Or, second solution: to set an mrk in the content and again for that special case use "source" and "target" with ref set to the id
of the mrk. Do we need to have a type value defined for the second option (like mtc:match is defined for the translation
candidates)?

Both options behavior would be quite different from the behavior for a note for example. So, the specification needs to be very
clear about how to do this (and well exemplified).
The other question then is how Change Tracking supports tracking the changes in segmentation if someone wants to do so?

A third possible option would be to always store the entire content (without the segment?) of source or target in <item> (still
saying that "content" for "source" and "target" mean the whole thing.

That last option may allow the tracking of segments too.
The drawback is the size. But overall it may be safer than with mrk or segments.

-ys


-----Original Message-----
From: Estreen, Fredrik [mailto:Fredrik.Estreen@lionbridge.com] 
Sent: Monday, December 7, 2015 3:06 AM
To: Yves Savourel <ysavourel@enlaso.com>; 'XLIFF Main List' <xliff@lists.oasis-open.org>
Subject: RE: [xliff] Inline codes in Change Tracking

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