Implementation Option: <group> of <trans-unit>

Hi all,

 

This email kicks off the thread to discusses the pros and
cons of representing segmentation in XLIFF through <group> of
<trans-unit>, as originally suggested by Tony.

 

The idea is to use a special type of <group> to
indicate where boundaries between <trans-unit> elements can be considered
“soft” boundaries (i.e. they can be changed without affecting the
ability to convert the file back to its original format) – in fact
representing boundaries that are guaranteed to have no skeleton content between
the <trans-unit>s.

 

Example:

 

<trans-unit id=”1”>

  <source xml:lang=”en”>First sentence.  Second
sentence.</source>

</trans-unit>

 

Could be re-formatted as:

 

<group reformat=”trans-unit” id=”1”>

  <trans-unit id=”1.1”>

    <source xml:lang=”en”>First
sentence.</source>

  </trans-unit>

  <trans-unit id=”1.2”>

    <source xml:lang=”en”>Second
sentence.</source>

  </trans-unit>

</group>

 

Which after translation could look like:

 

<group reformat=”trans-unit” id=”1”>

  <trans-unit id=”1.1”>

    <source xml:lang=”en”>First
sentence.</source>

    <target xml:lang=”sv”>Första
meningen.</target>

  </trans-unit>

  <trans-unit id=”1.2”>

    <source xml:lang=”en”>Second
sentence.</source>

    <target xml:lang=”sv”>Andra
meningen.</target>

  </trans-unit>

</group>

 

Here is what I see as pro’s and con’s with this
implementation:

Pros:

 
All facilities of the <trans-unit> are available for segments.

 
Reasonably close to functional
     compatibility with existing XLIFF specification. No new elements have been
     introduced. The functionality of existing elements has changed in a manner
     that mainly affects backward conversion (see Cons below).

 

Cons:

 
Breaks functional compatibility
     with existing XLIFF, as one <trans-unit> can effectively be replaced
     by a <group>. This changes the meaning of <group> and
     <trans-unit> from the way they work in the current XLIFF
     implementation. This will be confusing, in particular as the <group>
     and <trans-unit> element names are the same.

 
Functionality attached to the
     original <trans-unit> before it is split into a <group> cannot
     be represented without extending the <group> to also support things
     like <alt-trans> etc. Rather than extending the generic <group>
     in this way it would then seem natural to introduce a new element (e.g. <trans-unit-group>):

 

<trans-unit-group id=”1”>

  <trans-unit id=”1.1”>

    <source xml:lang=”en”>First
sentence.</source>

    <target xml:lang=”sv”>Första
meningen.</target>

  </trans-unit>

  <trans-unit id=”1.2”>

    <source xml:lang=”en”>Second
sentence.</source>

    <target xml:lang=”sv”>Andra
meningen.</target>

  </trans-unit>

</trans-unit-group>

 

But as it turns out that the <trans-unit-group> will
need all the functionality of the original <trans-unit>, would it not
rather make sense to keep the <trans-unit> as it is today, and instead
introduce a new element below it to represent the new functionality we want to
introduce? The structure of the example below is exactly the same as the
structure above, but we let the original <trans-unit> work as it does
today (it will not need to be replaced by some type of group):

 

<trans-unit id=”1”>

  <segment>

    <source xml:lang=”en”>First
sentence.</source>

    <target xml:lang=”sv”>Första
meningen.</target>

  </segment>

  <segment>

    <source xml:lang=”en”>Second
sentence.</source>

    <target xml:lang=”sv”>Andra
meningen.</target>

  </segment>

</trans-unit>

 

 
Difficulties arise when looking
     at how to handle <bpt>, <ept>, and <g> that span segment
     boundaries in the original <trans-unit>. This is an important issue
     that we will come across in almost all our representations.

 

 

Cheers,

Magnus