Re: [xliff-users] Storing native data in inline codes

[Wolfgang Textor <wtextor@codesco.com>]

Out of the options in the summary, I would prefer to store the native data in attributes. This would hide the information from parsers, regardless whether they can handle inline tags correctly or not. If you want to store arbitrary data, your XML engine should be able to escape it transparently, or you would encode it, e.g. as Base64.

I do not see a need for additional tags, as the existing inline and delimiter elements are plenty already. What I would like to see, however, is:
- more predefined values for the ctype attribute (have a look at Microsoft Word's character styles for a bunch of possible values), because this would allow tools to handle them and present something to the user;
- the ability to apply the font attribute to inline elements (maybe just better documentation: the attribute description of font mentions that font changes in document-type data could be marked using a <g> tag, but the <g> tag does not mention the font attribute at all);
- attributes like "size" or "color" for inline elements;
- an additional "data" attribute for inline elements with recommendations how to represent the data contained therein for storing native data in the existing tags.

You might want to extend the tentative schema for Option A with the data attribute for the <pc></pc> pair to support situations where only one set of native data exists for a paired span.

Regards,
Wolfgang

wtextor@codesco.com

Am 22.02.2011 um 22:31 schrieb Yves Savourel:

> Hello folks,
> 
> Over the past few weeks the inline markup sub-committee has been looking at ways to improve how to store the original data of inline codes for XLIFF 2.0.
> 
> We came up with a set of options that are illustrated here:
> 
> http://wiki.oasis-open.org/xliff/OneContentModel/Comparison#SummaryofthePossibleOptionsforRepresentingNativeData
> 
> We would greatly appreciate feedback from XLIFF producers and consumers on those different representations: potential issues, additional suggestions, preferences, etc.
> 
> Thanks,
> -yves
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xliff-users-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xliff-users-help@lists.oasis-open.org
>