From: unicode (firstname.lastname@example.org)
Date: Mon Jun 30 2008 - 23:33:38 CDT
It is *not* a matter of stability; it is a matter of correctness. The correct outcome is "SS".
On Mon, Jun 30, 2008 at 7:25 PM, unicode <email@example.com> wrote:
Kenneth Whistler wrote:Do I understand correctly that the special casing table will continue to contain the mapping from SHARP S (U+00DF) to "SS" as below:
The later proposal more correctly identified it as the
uppercase form of the SHARP S letter (esszet) and disconnected
the proposal from the untenable position that it was directly related
to "SS". As David Starner surmised, the casing stability issue
was dealt with by simply including no mapping from U+00DF to the
new uppercase character.
# The German es-zed is special--the normal mapping is to SS. # Note: the titlecase should never occur in practice. It is equal to titlecase(uppercase(<es-zed>))
00DF; 00DF; 0053 0073; 0053 0053; # LATIN SMALL LETTER SHARP S
when there is now an official uppercase version of SHARP-S?
I mean: great for stability, but when one runs upper(0xDF) what is the correct outcome?
Will we we need an exception or override property to the special casing property?
The current result of upper(0xDF) in SQL is as follows:
SQL Server: 0xDF (still lowercase!)
will they both have to change?
This archive was generated by hypermail 2.1.5 : Mon Jun 30 2008 - 23:36:29 CDT