RE: [xliff-inline] Req 1.15 Representation of invalid XML characters

[Yves Savourel <ysavourel@enlaso.com>]

Hi Christian,

>> - Writers MUST encode all invalid XML code points 
>> of the inline content using <cp>.
>
CL> We may need to include an explanation of "invalid/valid
> XML code point". We should also note that the "cp" 
> idea is from Unicode (LDML).

Yes. For code point, We should probably talk about "character" rather than "code point" here. The character's code point being just the value of 'hex'.


> - Readers MUST process all <cp> elements regardless 
> whether their hex value is a valid or invalid XML 
> code points.
>
CL> How can we define "process"?

Maybe interpret, or convert would be better (more specific).


> ... If the process is not terminated, the code point 
> with the error MUST be replaced with a question 
> mark character (U+003F). [[or should we use U+FFFD?]]
>
CL> I am not sure about both options. I would rather tend 
> towards a characters (or even string) which makes its 
> origin (namely a replacement stemming from a 
> process related to invalid hex code) clear.

U+FFFD would be the closest character for that. But maybe a string expression could be better I suppose. Something like "[!invalid-cp-hex:'hex:badvalue'!]"?

This opens the question about error handling in general in the processing expectation. An error is a problem that should not be dismissed, and allowing "fall-back" like this may lead to bad practices. The bottom line is the file should be fixed. Maybe the expectation should be:

- If the value of the hex attribute is invalid, the Readers MUST generate an error and MUST terminate the process.

But then, this prevents tools to catch several errors in one go...

-ys