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

["Lieske, Christian" <christian.lieske@sap.com>]

Hi Yves,

Great. Please find some comments below.

Cheers,
Christian

-----Original Message-----
From: Yves Savourel [mailto:ysavourel@enlaso.com] 
Sent: Samstag, 13. August 2011 12:24
To: xliff-inline@lists.oasis-open.org
Subject: RE: [xliff-inline] Req 1.15 Representation of invalid XML characters

I went ahead and added <cp> support for inside the inline codes <sc>, <ec>, and <ph>, as well as in <data> for the storage outside the content. It wasn't too difficult to implement.

As for the processing expectations I would suggest something like this:

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

- Writers SHOULD NOT encode valid XML code points of the inline content using <cp>.

- 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"?

- If the value of the hex attribute is invalid, the Readers MUST generate an error and MAY terminate the process. 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.

The latest snapshot of Rainbow implement all this.
(http://okapi.opentag.com/snapshot)

Cheers,
-ys


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php