RE: [xliff] Simplified XLIFF element tree

[Yves Savourel <ysavourel@translate.com>]

> As Andrzej suggested, a "text block" can be represented using 
> the existing <group> element. Each component "segment" can 
> be stored in its own <trans-unit>.

The problem with using <trans-unit> for segment is that it doesn't support the separation between extraction and segmentation by other tools.

For example, if tool ABC creates an XLIFF document with non-segmented entry looking like this:

<trans-unit id='id1'>
 <source>First sentence. Second sentence.</source>
</trans-unit>

The tool DEF, which perform the segmentation, has to re-create something like this:

<group id='id1'>
 <trans-unit id='id1-seg1'>
  <source>First sentence. </source>
 </trans-unit>
 <trans-unit id='id1-seg2'>
  <source> Second sentence.</source>
 </trans-unit>
</group>

Basically it has to re-create another XLIFF document.
 
I do understand the shortcomings of the <seg-source> approach and why using <trans-unit> seems like a good solution in 1.2: it allows to get metadata attached to segments.

But we are thinking for 2.0 and I'm sure we can imagine something that allows us to make the distinction between an extraction unit and a segment.

-ys