- From: <bugzilla@jessica.w3.org>
- Date: Tue, 19 Jun 2012 16:42:38 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17282 --- Comment #1 from Henry Zongaro <zongaro@ca.ibm.com> 2012-06-19 16:42:38 UTC --- Tim, thank you for pointing out that discrepancy. Section 3 of the Serialization 1.0 Recommendation[1] was slightly less restrictive. It stated that the permitted values of the normalization-form serialization parameter were, "One of the enumerated values NFC, NFD, NFKC, NFKD, fully-normalized, none or an implementation-defined value." Although an XSLT 2.0 (or XSLT 3.0) implementation would never have supplied anything but an nmtoken as the value of that serialization parameter, it's conceivable that an XQuery 1.0 implementation could support an implementation-defined value for the normalization-form parameter that was not an nmtoken. As such, changing this to require the normalization-form parameter to be an nmtoken would be a backwards incompatibility. However, I think it's extremely unlikely that any implementation would actually have chosen an implementation-defined value for normalization-form that didn't have the lexical form of an nmtoken, and that the risk of actually breaking an implementation is vanishingly small. I support your proposal to introduce that restriction in Serialization 3.0. I am speaking only on my own behalf, not on behalf of the XSLT and XQuery Working Groups. [1] http://www.w3.org/TR/xslt-xquery-serialization/#serparam -- Configure bugmail: https://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 Tuesday, 19 June 2012 16:42:41 UTC