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

[Yves Savourel <ysavourel@translate.com>]

Hi everyone,


> Section 3.3: in XLIFF you can use a <ph> element for each isolated
> code too.

I don't think that is correct: in XLIFF 1.2 <ph> is meant to code a placeholder. <ph> has no pos attribute so you cannot preserve
the information about whether the code is an opening or closing. The <it> element is design for this (or <bx>/<ex> if you use that
notation).
I'm not saying that is what XLIFF/TMX 2.0 should do, just that it is how XLIFF 1.2 and TMX 1.4 are.



> Section 3.5: in TMX the idea of an inline tag is to have a container
> for markup. This section is against the requirements of TMX.

There is actually a requirement for the next TMX version that says: "all stored inline codes must be in element content"?

I think the fact that both TMX and XLIFF are using element content to store codes is not a *requirement*, it is just the way things
have been done so far (and the main reason is <sub>). This mix of code and text in TEXT nodes is making things more complicated for
processors, and if it is possible to improve on that I certainly hope that both formats will do it.



> Section 3.11: contradicts section 3.5

I don't think so. It depends how you store the code.
If it is stored in an attribute it works well with 3.5.



> Section 3.14: There are no nested "segments" in TMX. Subflows are not
> segments, they are parts of a segment.
>
> Section 3.15: Subflows are not segments in TMX. A subflow is an
> integral part of a segment.

I think here "segment" does not mean <seg> but rather refer to the general concept of segment (for example a sentence). Subflows are
separate runs of text and fall into that definition.

Maybe the requirement would be more clear labeled: "Should not store a flow of text within another one."

I think the requirement expressed here is that: It's not because the original format from which the text is extracted chooses to
represent two distinct flows of text by nesting one within the other that TMX/XLIFF should do the same. Storing such flows in
distinct units have many technical advantages. 



> Section 3.17: In TMX text is already segmented.

TMX <seg> elements can be paragraphs and may need to be re-segmented. Therefore having segmentation information on inline codes is
useful. If some segmentation hints can be defined for XLIFF, there is no reason not to not have them in TMX as well.

And this is a good example of why a common markup is so important: It may not be immediately obvious how some of the information may
apply to one given format, but because the content both formats are storing is the same and can interact, it is important that both
formats can store the same information.


Kind regards,
-yves