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

["Lieske, Christian" <christian.lieske@sap.com>]

Hi Yves/all,

Thanks for getting back to me quickly.

Please find some replies related to your feedback below (see the "CL>").

Best regards,
Christian

-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com] 
Sent: Freitag, 1. Oktober 2010 21:33
To: xliff-inline@lists.oasis-open.org
Subject: RE: [xliff-inline] Personal Action Item to Review the existing Requirements

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>").

CL> Sorry if I used inappropriate terminology. I started to promote the term "generic inline markup" 
CL> (especially in an XLIFF context - see http://markmail.org/search/?q=generic+inline+markup&q=list%3Aorg.oasis-open.lists.xliff) 
CL> in order to
CL>  a. clearly separate it from specific inline markup (such as the "em" in HTML)
CL>  b. indicate that the markup cannot is meant to be usable in various "host" formats (e.g. in the successors of current XLIFF and TMX versions)

> 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.

CL> I would not have a problem, if an explanation of the "generic inline markup" (sorry for using that term again) would cover the following:
CL>   a. inline markup of the original vocabulary
CL>   b. "illegal/non-XML" characters
CL>   c. "special" characters (e.g. for hotkeys or accelerator keys)
CL>   d. means for carrying "new" information (i.e. markup or information non present in the original material) 

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

Could you elaborate?

CL> No :-) I simply don't understand what's meant by "Must be able to associate the same codes between the source and the target segments".
CL> Is it
CL>   a. have identifiers for the generic inline markup (so that you can see that it represents the "italics" in the original)
CL>   b. have a mechanism to enforce that the same markup is present in different versions of content (e.g. the source language and the target language)
CL>   c. ...

> 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.

CL> I wonder if something like
CL>	For the implemementation of any requirement, a conformance clause should be considered.
CL> would also be a possible additional "Guiding Principle".


Cheers,
-yves



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php