From: Mark Davis (mark.davis@icu-project.org)
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".
Mark
On Mon, Jun 30, 2008 at 7:25 PM, unicode <unicode@i18n.ca> 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
> 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:
> 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