[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-inline] Various XML constructs in inline content
Hi Christian, >> --B) Why should we have a special case when the original format >> is XML? Here again it seems this XML-specific guidance should >> be part of a representation guide, not part of the specification. >> CL> I agree. There should be no special case. I wonder, however, > if we should turn observation into a general rule for XLIFF: > XLIFF and related processes should be able allow roundtripping > of any kind of native data (example: for XML as native format, > processing instructions, comments etc. should survive conversions). Sounds good. >> ...Is this means "to represent XML PIs or XML comments, you must >> use the representation described in the generic inline markup? >> I don't think PIs and comments outside extracted content should >> be covered by the inline markup. For example, we could have a >> PI somewhere in the structural markup of the original XML. >> That one should be handled by the "normal skeleton". > CL> Your paraphrase is correct. However, I understand your point > that it might be good to have two different ways of representing > PIs or XML comments. I wonder, however, which mechanisms a > filter would need to implement if he wants to distinguish the > two occurrence types. He first would need to understand what > the "structural markup" is. I should use the proper term based on our definitions: By "structural" I meant "block-level" (http://wiki.oasis-open.org/xliff/OneContentModel#Definitions.2BAC8-Terminology) I would say: if the PIs or comment occur within a block-level markup it should be treated like other block-level markup, and if they occur within inline-level markup they should be represented like other inline-level markup. -ys
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]