RE: [xliff-inline] Various XML constructs in inline content

[Yves Savourel <ysavourel@enlaso.com>]

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