OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xliff] Simplified XLIFF element tree


----- "Andrzej Zydron" <azydron@xtm-intl.com> wrote:
> For pre-segmented XLIFF systems:
> 
> <group id='e1' extype='para'>
> <trans-unit id='u1'>
> <source>This is the first sentence.</source>
> <target>Pierwsze zdanie.</target>
> </trans-unit>
> <trans-unit id='u2'>
> <source>This is the second sentence.</source>
> <target>Drugie zdanie.</target>
> </trans-unit>
> </group>
> 
> For unsegmented XLIFF systems a solution might be:
> 
> <group id='e1' extype='para'>
> <extr-text id='e1'>
>          This is the first sentence. This is the second sentence.
> </ext-text>
> </group>
> 
> The segmenting XLIFF editor would then generate the following:
> 
> <group id='e1' extype='para'>
> <extr-text id='e1'>
>          This is the first sentence. This is the second sentence.
> </extr-text>
> <trans-unit id='u1'>
> <source>This is the first sentence.</source>
> <target>Pierwsze zdanie.</target>
> </trans-unit>
> <trans-unit id='u2'>
> <source>This is the second sentence.</source>
> <target>Drugie zdanie.</target>
> </trans-unit>
> </group>

I see a few flaws with this approach:
1) Having to duplicate source text ( -> same approach as <seg-source>)
2) No easy way of re-arranging segments
3) No easy way of storing data that is between segments
4) Every trans-unit in the file will be within a group element, even though it's one segment
5) It's going to be a pain to work with in editors and processing tools, as <trans-unit> elements would have to be created on demand based on if it segmented or not. And on re-segmentation, the <source> would change.
6) If <extr-text> is 'optional' it creates even more problems..

> The benefit of using 'group' in this way is that we are not inventing
> new elements and is totally backwards compatible with XLIFF 1.2. The 
> last thing we want to do is to introduce any fundamental change to the
> XLIFF structure. For non-segmenting systems we have the new optional 
> <extr-text> element. This should solve both problems.

I think this touches on the core of this discussion. Part of what I and others will present over the symposium is really a major revision of XLIFF towards a 2.0 version, rather than minor backwards compatible changes. Tools that work with 1.x today will not work with 2.0 without modification. 

Great to see the discussion on 2.0 pick up!

cheers,
asgeir



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]