RE: [xliff] Wiki Document related to "Generic Inline Markup"

[Yves Savourel <ysavourel@translate.com>]

Hi everyone,

> Regarding  (2), my temptation was to go right to item "2. Should be able to represent 
> balanced paired-codes" and add a personal opinion note under the "First way, using 
> <itag>" and "Second way, using empty <itag>" to say that I do not like either (mostly 
> for marking up XML). I strongly wish TMX and XLIFF could express a "third, and preferred 
> way," that basically mimics the <g> example in XLIFF: "<itag x='1'> type="bold">bolded
> </itag> text" I wonder if I am in the minority with this opinion. Our discussions kind
> of make me think most people on the TC agree with this point of view.

I think there is one aspect of the content markup that has strong implications in how inline codes may be represented, and maybe we
should settle that one first.

It's the representation of sub-flows.

Both current versions of TMX and XLIFF have the <sub> element for this.

I think Arle mentioned that he had feedback about some people who had a strong need for <sub> to stay. Would it be possible to go
into more technical details about this?

From my experience <sub> is:

a) Rarely used.

b) Is a pain to implements, because it, more or less, forces to handle the content recursively. This means it pushes much higher the
entry level for a developer to implement a TMX/XLIFF reader.

c) Is actually not implemented at all by many tools that supports either XLIFF or TMX.

If someone can actually output a sub-flow marking it up with <sub>, there is very little difference between that and implementing it
as a true separate item. The difficulty is mostly in identifying what parts of a content are sub-flows.

From a logical viewpoint there are no advantages I can think of to store a sub-flow nested within its parent in either TMX or XLIFF.
There are however, many drawbacks.

And lastly, having to store a nested sub-flow within a chunk of code has a big impact in how we can represent chunks of codes in
general: It forces to store them in elements and prevent to store them in attributes. This reduces greatly the representation
options we have.

So, are there compelling reasons to keep sub-flow nested for 2.0?

Cheers,
-yves