17282 2012-06-01 10:51:21 +0000 [SER30] Unicode normalization form values 2012-07-10 02:19:24 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Serialization 3.0 Working drafts PC Windows NT CLOSED FIXED P2 normal --- 1 tim zongaro public-qt-comments oldest_to_newest 68491 0 tim 2012-06-01 10:51:21 +0000 XSLT 2.0 requires implementation-defined normalization-form values to be nmtokens. The serialization spec makes no such restriction. Is there a case for such a restriction? <xsl:output ... normalization-form? = "NFC" | "NFD" | "NFKC" | "NFKD" | "fully-normalized" | "none" | nmtoken ... /> 69244 1 zongaro 2012-06-19 16:42:38 +0000 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 69756 2 zongaro 2012-07-10 02:18:29 +0000 At the joint teleconference of the XSLT and XQuery Working Groups of 26 June 2012,[2] the working groups decided to change the definition of the normalization-form serialization parameter to require the value to be an NMToken. Tim, as you were in attendance at the call, I will assume the decision is acceptable to you, and close the bug report. This will be implemented in the next working draft of Serialization 3.0. [2] https://lists.w3.org/Archives/Member/w3c-xsl-query/2012Jun/0135.html