Re: Your comments on Character Model Fundamentals [LC070, LC074, LC075, LC079, LC080, LC081, LC082, LC083, LC084, LC085, LC086, LC087, LC088, LC089]

* Martin Duerst wrote:
>Well, if you want to upper-case a string, you will have to make
>that decision anyway. And then there might easily be cases where
>actually there is a precombined version for lc, but not for uc,
>or the other way round, so you have to deal with these anyway.

The difference is however that in one case API designers have to deal
with it while in the other case API users have to deal with it.

> >But not the argument and whether there is actually such a need is
> >debatable, I know of quite a number of APIs where '?' == uc '? but
> >'?' == uc '?', so there are quite a number of people who disagree
> >that this is an absolute requirement
>
>This is a question of how to define the actual action of the
>function, not a question of what should be used as argument and
>return types.

But there is no point in returning a string if the string will only
ever consist of exactly one character -- defeating the rationale in
charmod.

>No, it doesn't. First, this isn't charmod's business. To some extent,
>it's Unicode's business. To some extent, it's application specific.

Yet charmod states that "SS" is the "proper" result for uppercase('ß').

>What about
>
>   Specifications of APIs SHOULD use strings rather than characters as
>   arguments and return types.
>
>I'm affraid that otherwise, we get into discussions of what exactly
>'prefer' means :-).

Well, use it unless you know you don't "need" to... I guess I could live
with the text but I think requiring a preference rather than usage is
better. I don't think people would argue about using "prefer" here as
the text cannot be much clearer without getting more specific; all you
want is that API designers do not use chars by accident of false
assumptions...

>I don't know. It would definitely look better than keeping the
>sz in its lower case form, which would look weird. I know that
>CSS mentions cases such as the Dutch IJ for its :first-letter
>pseudo-class.

Well, currently it is not realistic to expect implementations to do
that... I would agree in principle but I clearly prefer specifications
that get fully implemented.

Received on Thursday, 28 October 2004 16:55:02 UTC