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

[Yves Savourel <ysavourel@enlaso.com>]

Hi Rodolfo, Helena, Stevens, all,

Thanks for the feedback.

To summarize:


-- a) Syntax of the hex value:

If there is a XSD type we can use, it seems like a good idea to do so. If it allows only upper-case, then so be it.

"hex - mandatory. Hexadecimal value of the character's code point.
	The value can be padded with zeros and MUST be in uppercase."


-- b) Allowing or not to use cp for characters valid in XML.

I would agree with Rodolfo. Being strict is probably better.
Thoughts anyone?


-- c) Error handling.

I understand Rodolfo and Stevens viewpoint: the file should be valid and that's it. No need for expected behavior after that.

I was trying to think about the cases where tools want to go beyond the error because it's practical: one may want to get a list of the 25 first errors for example and therefore not stop at the first one. Should we care about what happened to the data processed after the error? 


- Writers MUST encode all invalid XML characters of the content using <cp>.
- Writers MUST NOT encode valid XML characters of the content using <cp>.
- Readers MUST process all <cp> elements. (--> not sure if it's needed anymore)
- If the value of the hex attribute is invalid, the Readers MUST generate an error.
	- Upon error, Readers MUST consider the whole document invalid, they MAY continue the process only for the purpose of finding additional issues in the document.

Or should we just not mention anything about further processing.

This case is just one of the error cases we will have to handle in processing expectations, not just for the inline codes. Users expect some possibility of error recovery in tools. Should we provide guidance for that or not?

-ys