Implementation Option: <segment> inside <trans-unit>

Hi all,

 

This email is to kick off the thread discussing the option
of representing segmentation in XLIFF though a new <segment> element at
<trans-unit> level. This is the representation used throughout my samples
in the document I wrote to develop the process and use cases for segmentation
in XLIFF (http://www.oasis-open.org/apps/org/workgroup/xliff-seg/download.php/6067/Case%20for%20Segmentation%20in%20XLIFF%20Draft%201.zip).

 

 

The idea is to allow optional <segment> elements
directly below the <trans-unit>, where each segment contains a
<source> and optional <target>, <alt-trans> etc. The
functionality of the <trans-unit> remains the same as in today’s
XLIFF implementation.

 

Here are some pros and cons that I can think of with this
model:

 

Pros:

 
Clear and straight-forward way
     of representing segmentation as a structure within the <trans-unit>.
     

 
The functionality of all
     existing XLIFF elements (e.g. <trans-unit>, <source> and
     <target>) remains the same as today. The new segmentation functionality
     is handled entirely by the <segment> element.

 
Strong coupling between source
     and target versions of segments is enforced by the schema.

 
<alt-trans> for
     individual segments can be represented in a natural way.

 
State in the translation process
     can be clearly indicated for individual segments (using state attribute
     for <target>).

 
<note> can be attached to
     individual segments in a natural way.

 
Backward compatibility with
     existing XLIFF. The <segment> element is optional. As long as it is not
     used we have 100% compatibility.

 

Cons:

 
Breaks forward compatibility
     with existing XLIFF if the <segment> element is used. The content of
     all <segment> elements inside a <trans-unit> must be “merged”
     for the file to be compatible with the current XLIFF specification. 

 
<alt-trans> for an entire
     <trans-unit> must be placed after the last <segment>. It may
     not be structurally clear enough that it corresponds to all <source>
     elements taken together.

 
Handling <bpt>,
     <ept>, and <g> that span segment boundaries in the original
     <trans-unit> is not straight forward. This is an important problem that
     we see with other representations too.

 

 

NOTE: On the compatibility issue, is it not reasonable to
assume that the use of a new feature in a future version of XLIFF may break forward
compatibility with an earlier version? That is at least the case with XLIFF 1.1
vs. XLIFF 1.0 – new tags can be used in XLIFF 1.1 that would have to be
removed for the content to be compatible with XLIFF 1.0. After all, if no new
elements or new structure were introduced there would be no need for a new
version…

 

Cheers,

Magnus