RE: [xliff] Simplified XLIFF element tree

Hi everyone,

> For systems that have chosen to pre-segment,
> there should not be any compulsion to do 
> otherwise.

I completely agree.
And I didn't see any of the proposals so far trying to preventing a tool to pre-segment.


> I always viewed the the original <seg-source> 
> proposal with a great deal of regret.
> In my mind it was a very bad choice in XLIFF 1.2.
> and has proven to be so.

Several tools work perfectly well with the current 1.2 segmentation. They also inter-operate well.
Which is more than we can say about the non-1.2-standard way of using trans-unit as segments holder. The example I ran into last week is only one among the several distressful cases were we could simply not use the XLIFF files generated with such pre-segmented content.

The two main issues with <seg-source> are: a) it does not allow to set 1.2 flags like state and others at the segment level; and b) it duplicates the content. So the 1.2 segmentation representation certainly needs a make-over, but as far as my experience it has been proven to work fine for tools that implement it.

What has been proven a dangerous adventure is choosing to use proprietary ways of representing segmentation that cause a lack of interoperability with other tools.

Cheers,
-yves