OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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.


-----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?


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


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:revisions appliesTo="segment" ref="s1">
    <ctr:item property="content">This is a <pc id='1'>sample</pc></ctr:item>
 <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?). 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]