From: Mark Davis (email@example.com)
Date: Mon Jun 30 2008 - 22:02:21 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 <firstname.lastname@example.org> wrote:
> Kenneth Whistler wrote:
>> 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.
> 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 German es-zed is special--the normal mapping is to SS. # Note: the
> titlecase should never occur in practice. It is equal to
> 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
> The current result of upper(0xDF) in SQL is as follows:
> Oracle: "SS"
> SQL Server: 0xDF (still lowercase!)
> will they both have to change?
This archive was generated by hypermail 2.1.5 : Mon Jun 30 2008 - 22:05:03 CDT