xliff-inline — archive

[Yves Savourel]

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 by "