RE: [xliff] Minimum set of container elements for XLIFF 2.0

[Yves Savourel <ysavourel@enlaso.com>]

Hi Rodolfo, Bryan, all,

> We don’t need <group>. With <unit> as container 
> of multiple <segment> elements we have enough. 
> You can consider that the old <group> is equivalent 
> to the new <unit> and the old <trans-unit> is 
> the equivalent of the new <segment>/<ignorable> pair.

You make it sound like the v1.2 <group> is used to group segments and that a <trans-unit> is a segment. That is incorrect. The Segmentation section[1] of the v1.2 specification clearly defines how to represent segmentation using <trans-unit>/<seg-source>/<mrk mtype='seg'>. Any other way to represent segmentation in v1.2 is not the standard one and is not interoperable.

But we went through that discussion several times in the past years, and there is not point rehashing it :)

More importantly (and regardless of v1.2 segmentation) in v2.0 we need <group> to provide a way to map (completely or partially) the hierarchy/structure that may exist in the original document. Basically to delimit different sets of units. For example the units in a given table, or in a dialog box, a menu, or to separate different types of content, etc. Nothing mandatory there obviously, but the possibility to structure the extracted content is needed and should be part of the core.

I hope to be able to finish the preliminary proposal for this soon. There is a bit of it already there: [2]

Cheers,
-yves


[1] http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#Struct_Segmentation
[2] http://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/Grouping