RE: [xliff-inline] Personal Action Item to Review the existing Requirements

[Yves Savourel <ysavourel@translate.com>]

Hi Christian, all,


> 1. I would tend to rephrase =20
> ...#1.5...
> 
> From my understanding, the requirement is to associate meta
> data with the generic inline markup, not with a span.

What do you call "generic" inline markup? (the requirements do not include that word anywhere)

Mmm... To me this requirement simply says that the format should provide a way for a user agent to associate some meta data with a span of content. And that is that mechanism that would be the potential inline markup. (In "some <AAA type='term'>text</AAA>" it's "text that is a term, not the tag "<AAA>").



> 2. I would tend to rephrase
> ...#1.8...
>
> I understand that the focus is on XLIFF and TMX. However, 
> from my understanding the generic inline markup may also find 
> usage scenarios outside of XLIFF and TMX.

I think the reference to XLIFF and TMX here is just to exemplify what a "segment" means in their context.


> 3. I am a bit unsure about
> ...#1.6...
>
> The reason is the "must be able to". From my point-of-view, this
> introduces a degree of freedom (i.e. you can do it but don't have to).
> Thus, the door for inconsistent handling/implementation is opened.

It does introduces a degree of freedom. I'm not sure we always want a display-friendly representation in the code for informational purpose.
But I think ultimately those type of issues (i.e.: should it be mandatory or not) are probably little relevant in the requirements: we know we have to find a way to represent this, whether it'll be a mandatory feature or not can be decided as we work on the actual implementation, or even after.


> 4. Requirements
> ...1.7... (text-equivalent)
> ...1.15... (illegal chars)
>
> Have caused me to revisit my understanding of "inline markup".
> So far, I only had "genuine" markup (e.g. italics, or bookmarks) on my list.
> Now, I see that "special characters" (eg. for hotkeys/accelerator keys) and
> "illegal characters" should also be covered. I suggest to make this clear
> in an introductory section (possibly the "glossary/terminology" section)

There are things we want to be able to represent in a segment that do not exist at all in the original text. For example in:

"The <b>printer Schtroumpf-Model56</b> is efficient.",

we may have an (imaginary) XLIFF output like this:

"The <AAA id='1'>printer <BBB translate='no'>Schtroumpf-Model56</BBB></AAA> is efficient."

Where the XLIFF code <AAA> represent the original bold codes, and <BBB> is use to attach additional info within the segment (here that a span of text is not to be translated).

But I see what you mean. In the current definitions we mostly talk about the terms in reference to the original format and inline code is defined like that. To me "inline markup" refers to XLIFF not to the original format.

The scope and SC name refer to the inline markup for XLIFF, which covers representing inline codes of the original format. But not just that: any information that is in a segment.

Note that for 1.7 I think the '&' example qualifies as inline code in the original format, based on our current definition.



> 5. Unfortunately, I am not clear about
> ...#1.9...

Could you elaborate?



> 6. I am tempted to suggest an additional "Guiding Principle"
> Wherever possible, data categories or representation mechanisms
> from other standards should be considered.
> ...

Sounds like a good spelling out of a common-sense thing.


Cheers,
-yves