W3C home > Mailing lists > Public > public-qt-comments@w3.org > December 2009

[Bug 8456] Behaviour of 'FULLY-NORMALIZED' not well defined in fn:normalize-unicode

From: <bugzilla@wiggum.w3.org>
Date: Tue, 08 Dec 2009 15:35:40 +0000
To: public-qt-comments@w3.org
Message-Id: <E1NI26G-00068M-G3@wiggum.w3.org>

--- Comment #1 from Michael Kay <mike@saxonica.com>  2009-12-08 15:35:40 ---
This issue is discussed here:


a discussion which started with my observation

"It's not at all clear to me that supporting "fully-normalized" form
makes any sense at all. Whereas the Unicode normalization forms all describe
an algorithm for normalizing data, the "fully-normalized" form is described
only as a property of a string. There is no algorithm provided for making a
string fully-normalized, and the only algorithms that one might come up with
involve losing information."

The next message in the thread summarizes what we concluded about the

"... a check that the first character in the string being normalized is
a base character (e.g. has a combining class of 0). If the last test
fails, a space is inserted at the start of the data to carry the
combining mark."

If my memory serves me right, we were assured that the algorithm would be
properly described in a future version of CharMod, and we felt that it needed
to be fixed in CharMod rather than in our specs. Perhaps that was wishful
thinking (many things related to I18N are).

For my own part, if I remember right I decided not to support this optional
feature until it was better specified.

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 Tuesday, 8 December 2009 15:35:49 UTC

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