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

xliff-seg message