RE: [xliff] Simplified XLIFF element tree

[Yves Savourel <ysavourel@translate.com>]

Hi everyone,

>> 1) Having to duplicate source text
>> ( -> same approach as<seg-source>)
>
> If you are going to show the <extr-text> then 
> it must be left alone, otherwise you are changing the context.

I don't see a problem with having markup in the source text that is used to delimit specific properties of the text, in addition to the one used for the inline codes. One of the properties can be the segmentation. another can be terms, etc.

If we have clearly defined processing expectations associated with some elements, reading the original un-segmented from such marked up content should be easy.


>> 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.

Two notes on this:

a) To have a segmentation representation backward compatible we would need to use <seg-source> in some way: That is the only way to represent segmentation described in the XLIFF 1.2 specification.

b) But it's a moot point anyway: to me, 2.0 should not concern itself with backward compatibility.
We should be able to create new structures, remove some, do anything that makes XLIFF better.
I thought that was an established start point for 2.0.
If it is not then we need to tackle that before anything else.

Actually I'm even thinking we should make sure 1.2 tools cannot read 2.0 files. This would avoid any half-implementation based on some vague changes in 1.2 readers. I suspect a large part of the 2.0 changes will be the expected processing associated with the elements/attributes and we want to avoid 2.0 files being processed like 1.2 ones.

Cheers,
-ys