Bug 17282 - [SER30] Unicode normalization form values
Summary: [SER30] Unicode normalization form values
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Serialization 3.0 (show other bugs)
Version: Working drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Henry Zongaro
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-01 10:51 UTC by Tim Mills
Modified: 2012-07-10 02:19 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Mills 2012-06-01 10:51:21 UTC
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
  ...  />
Comment 1 Henry Zongaro 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
Comment 2 Henry Zongaro 2012-07-10 02:18:29 UTC
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