RE: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Dec-13-2011 - Summary

[Yves Savourel <ysavourel@enlaso.com>]

Regarding the thread on <sc>/<ec>
(http://lists.oasis-open.org/archives/xliff-inline/201112/msg00031.html)
Moving it to the main list for Rodolfo.

>>> Rodolfo:
>>> As Bryan says, we should not allow having <sc> and 
>>> the corresponding <ec> in the same segment. The use 
>>> of <sc>/<ec> pair should be reserved only for tags 
>>> that start and end in different segments.
>>
>> Andrew:
>> Just to be clear, is it agreed that <sc>/<ec> should 
>> also be used for overlapping markup?
>
> Rodolfo:
> There is no need to use <sc>/<ec> for overlapping markup.

Currently we have:

- <ph> is for standalone codes (e.g. <br/>)
- <pc> is for well-formed span-like codes.
- <sc>/<ec> are for non-well-formed span-like codes.

Span-like codes that are well-formed in the original format can be made non-well-formed in XLIFF:

a) when a segment break comes inside the span.

b) when an annotation (<mrk>) is added and overlaps the span. In such scenario both ends of the span stay in the same segment. I don't think we want to suddenly lose information by changing both ends into a <ph> element, especially since the annotation may be removed and the well-formness of the span restored at any time.

Here is an example:

1) Initial markup with a well-formed span-like code:

<source>text in <pc id='1'>bold</pc></source>


2a) With added annotation (using <sc>/<ec>):

<source>text <mrk type="comment" value="'in bold' should be translated as 'bolded'">in <sc id='1'/>bold<ec rid='1'/></mrk></source>


2a) With added annotation (using <ph> instead of the current <sc>/<ec>):

<source>text <mrk type="comment" value="'in bold' should be translated as 'bolded'">in <ph id='1'/>bold<ph id='2'/></mrk></source>

As you can see in the case 2b), we would lose the information that the two codes are related. So when the annotation is removed, we would end up with a different markup than the initial:

3) after removing the annotation from 2b):

<source>text in <ph id='1'/>bold<ph id='2'/></source>

Sure, we could add an attribute in <ph> to carry the information about the relationship between the two codes, but why overload that element when we already have <sc>/<ec> available?

If the semantic of non-well-formed span-like codes is carried by <sc>/<ec> those should be the elements used everywhere for that purpose. It would be inconsistent to have the same semantic sometimes carried by <ph> and sometimes carried by <sc>/<ec>.

And, sure, all semantics could be carried by <ph> all the time. But that is a different debate.

Cheers,
-yves