Status of Inline markup for XLIFF 2.0

[Yves Savourel <ysavourel@translate.com>]

Hi everyone,

Since the subcommittee is inheriting the work of the TC on inline markup there are two tasks we need to tackle before we can start discussing implementation solutions:

1) Dispose of the list of scope items
2) Finalize the list of requirements

I would like to try to finish #1 as soon as possible so we can move to #2.
In #1 we have three un-resolved items:


-- 3.1.2. Canonical representation of native content:
(http://wiki.oasis-open.org/xliff/OneContentModel/Requirements#CanonicalRepresentationofnativecontent)

It seems the text of the question is broader than it should: "Should there only be one physical representation for a given native representation (wrt codes, inline-markup, 'skeleton' data, sub-flows)?"

Since we are concerned here only with inline data, maybe this could be reduced to "Should there only be one physical representation for a given native representation of inline native code?"

Then it seems (correct me if I'm wrong) the question is: should we have two ways to represent native inline codes?

-a) One that is a physical. For example replace <br/> by "<x id='1'/>

-b) One that is more indirect. For example defined some rules somewhere saying "<br/>" is the same a an "<x/>" code. (like ITS).

I think b) would make things too complicated because it would assume some associated rules and a lot of pre-processing to be implemented. So I would propose to simply have one concrete way of representing abstract inline codes.

[PROPOSED RESOLUTION]: "The proposed inline markup will be a concrete abstract notation of the native codes it represents."


--- 3.1.5. XML Implementation
(http://wiki.oasis-open.org/xliff/OneContentModel/Requirements#XMLImplementation)

One point of disagreement is using ITS or not as part of the XLIFF markup.
I think we don't need to resolve this disagreement here: It is an implementation issue.

I would propose to resolve it when we get to how do we implement some of the inline information. For example: if we have a span of text that should not be translated will 2.0 use something like <mrk its:translate='no'> or <mrk type='protected'>, or something else.

[PROPOSED RESOLUTION]: "The proposed inline markup will not required backward compatibility with older versions of XLIFF, may or may not be defined in a specific namespace, and may or may not include other namespaces."


--- 3.1.6. General scope
(http://wiki.oasis-open.org/xliff/OneContentModel/Requirements#GeneralScope)

This last entry may be superfluous now that we are tasked with defining the inline markup so it could potentially be used in both XLIFF and TMX.

[PROPOSED RESOLUTION]: We either discard the item, or rephrase it as: "The purpose of this specification is to define a content model that is task agnostic in the sense that it may be used in different contexts".


Please feel free to discuss those items by email even before the meeting.

Cheers,
-ys