- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 11 Dec 2009 23:48:41 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7935 --- Comment #4 from Michael Kay <mike@saxonica.com> 2009-12-11 23:48:40 --- At telcon 419 the following action was assigned: ACTION A-419-03 Michael Kay (bug 7935) to propose a non-normative clarification of normalize-unicode to explain the effect on unassigned codepoints (viz, that the function is idempotent). Proposed resolution (using the 2.0 baseline): 1. Update the reference to charmod to refer to the latest draft at http://www.w3.org/TR/charmod-norm/ with a dated reference (because it is a draft), and observe that this specification has not progressed beyond draft status. 2. For normalization forms NFC, NFD, NFCK and NFDK refer directly to http://www.unicode.org/reports/tr15/tr15-25.html rather than to CharMod. Retain the reference to CharMod only for FULLY-NORMALIZED. 3. Add the following statement: It is implementation-defined which version of Unicode (and therefore, of the normalization algorithms and their underlying data) is supported by the implementation. See [TR15] for details of the stability policy regarding changes to the normalization rules in future versions of Unicode. If the input string contains codepoints that are unassigned in the relevant version of Unicode, or for which no normalization rules are defined, the fn:normalize-unicode function leaves such codepoints unchanged. If the implementation supports the requested normalization form then it MUST be able to handle every input string without raising an error. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Friday, 11 December 2009 23:48:50 UTC