W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2012

[Bug 17282] [SER30] Unicode normalization form values

From: <bugzilla@jessica.w3.org>
Date: Tue, 19 Jun 2012 16:42:38 +0000
To: public-qt-comments@w3.org
Message-Id: <E1Sh1Vm-0003ha-Tq@jessica.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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:39 UTC