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

[Yves Savourel <ysavourel@enlaso.com>]

Hi Christian, all,

> 1. Basic:
> Whenever the native format of an XLIFF file is XML, XLIFF-related processes 
> have to ensure that the original XML (including any processing instructions
> and XML comments) can be reconstructed. Any information that is needed for
> this reconstruction has to be part of the XLIFF file (as opposed for 
> example to being part of an external skeleton file).


I'm not sure I agree with this formulation.
Let's fight :)

--A) It's not the role of the XLIFF specification to decide what a filter needs to preserve in the original format. That's for each tool to decide. E.g. Some may be fine with stripping out comments while other may want to keep them.

The role of the XLIFF format is just to provide a (well-defined) way to store "whatever info" the filter wants to pass through; not to decide what the information should be. This would be more the role of one of those representation guides we have, no?

--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.

--C) I don't think any information needed for the reconstruction should be part of the XLIFF file. We have actually a requirement that implies it does not have too: "1.12.1. to store only the XLIFF representation, discarding the native data"


> 2. Advanced:
> The XLIFF representation for processing instructions and XML comments 
> is the one for “generic inline markup”

Not sure I understand this.
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".

Cheers,
-yves