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