RE: [xliff] Opinion: importance of preserving XML markup and nodes

[Yves Savourel <ysavourel@translate.com>]

Hi Bryan, all,

> I really think each of them is bad.
> I think the following is a much better way (and, at least on 
> the XLIFF side, I will advocate strongly for this):
> <seg>
>  <itag type="b" x="1">XML</itag> is a general-purpose  
>  <itag type="i" x="1">specification</itag>
>  for creating custom markup languages.
> </seg>

I would tend to agree that preserving the XMLness is important.

However, there are cases where this cannot be done for various reasons: For example a segment break separating an opening tag from a
closing tag, or some format where codes are denoted by starting and ending marks possibly overlapping rather than by balanced codes.
This is illustrated by requirements 3.3 and 3.4 here:
 
http://wiki.oasis-open.org/xliff/OneContentModel/Requirements?action=show&redirect=Requirements#head-0162491596e263001714e9d13e95160
3df5ac8a4

http://wiki.oasis-open.org/xliff/OneContentModel/Requirements?action=show&redirect=Requirements#head-f473da5eae7f79e9ae89bc739831d3a
d8010c8f7

So, I think we do need a way to cater for those cases. And it just cannot be done using a structure that is XML-friendly.

I think Rodolfo's current <itag> is a unique solution that can handle both cases with one construct. This simplify the set of tags
to use by reducing the nice case (balanced pair) as a specific case of the nasty one (broken pair).

There is another solution that would use the same element for both cases, but differently. But it requires the code to be either not
stored, or stored in an attribute of <itag> rather than as the content of <itag>. If you do this, then the content of <itag> becomes
free to be used to represent the balanced-pair case, and with an empty content it can be used to represent the broken-pair case.

"[startB]Bold.[endB]"

<seg><itag x='1' bc='[startB]' ec='[endB]'>Bold.</itag></seg>

<seg><itag x='1' bc='[startB]/>Bold</seg>
<seg><itag x='2' ec='[endB]'/>.<seg>

Storing the code in an attribute has one important side effect: You cannot use <sub> anymore, because you cannot put a <sub> element
inside an attribute.

Which leads to my earlier question about whether <sub> was that important?

...and I now realize that the email apparently never made it to the mailing list... I guess I'll have to re-write it. But the bottom
line was: do we need <sub>? I think Arle had some concern about removing it because some people at OSCAR were considering it
important. Could we have some of their technical reasons for keeping it?

Cheers,
-yves