Req #17

[Yves Savourel <ysavourel@translate.com>]

Hi Bryan, all,

> One interesting thing, my misunderstanding aside, is the observation that:
>
>> it seems ironic to me that the example of what should be avoided in 1.17:
>>
>> This text is in <code native="[startBold]"/>bold<code native="[endBold]"/>.
>>
>> is (with the exception of the use of start tags instead of empty tags) exactly 
>> what is stated in 2.1 as "what we want to try to achieve:
>>
>> This text is in <code native="[startBold]">bold<code native="[endBold]">.

Actually the example in 2.1 is wrong, they need to be empty tags. I'll fix this.
And I don't think it contradict #17.
That example in #17 is also incorrect. It should really be:

This text is in <code native="<b>"/>bold<code native="</b>"/>.

As we shouldn't use an non-XML example on an item that pertains mostly to case where the original format is XML.


Let's start the discussion on #17:
Currently we have:

===
When processing well-formed XML, the best practice is to process the inline XML element as an XML node, not escaped start and end points
For example, if the entire inline element is contained in the segment, this XML: 

This text is in <b>bold</b>.

It is required to be able to preserve the node, like this: 

This text is in <code name="b">bold</code>.

It should be avoided to use a start and end marker in places of the actual code, like this: 

This text is in <code native="[startBold]"/>bold<code native="[endBold]"/>.
===

I think I understand the goal: it's to make sure the new inline markup does not prevent well-formed XML input data to be coded in XLIFF in a way that is not matching the original structure. In other words: when you have start/end tags in the original XML we would like a corresponding start/end XLIFF tags, when we have an empty element in the original XML we would like to have a corresponding empty element in XLIFF.

Is that correct?

If it is then it is very much in sync with the guiding principle #1.

I would reword the requirement differently, maybe something like this:

===
When processing well-formed XML, the markup should provide a way for the original XML elements to be stored in a way that allows the XLIFF inline markup to match the original structure. For example, given the following original XML content:

<img src='image.png'/> is a <b>beautiful</b> image.

We should be able to represent it in XLIFF using a markup where "<img src='imag.png'/>" is represented by an empty XLIFF element; and "<b>"/"</b>" are represented by a unique XLIFF element that encloses "beautiful".

For instance, using a representation such as this imaginary one:

<code1 data="&lt;img src='image.png'/>"> is a <code2 start="&lt;b>" end="&lt;/b>">beautiful</code2> image.

As opposed to this other imaginary representation:

<code1>&lt;img src='image.png'/></code1> is a <code2 id='1'>&lt;b></code2>beautiful<code3 id="1">&lt;/b></code3> image.
===

What do you think?
-ys