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
