On 7/13/05, Michael Sperber <xxxxxx@informatik.uni-tuebingen.de> wrote:
>
> You guys still need to get your terminology straight: The case mapping
> is perfectly well-defined---you just don't like the definition.  That
> I can sympathize with, but the whole case-folding issue doesn't have
> any easy solutions, as you point out.

[Please indicate where I've mistaken my terminology and I'll correct it.]

The case mapping does not match the case mapping defined by the
official Unicode standard, locale-aware or otherwise.

What the SRFI defines is a hack, using only one part of the Unicode
case mapping as provided in the UnicodeData.txt file.  That file does not
describe the Unicode standard - it is just a data file, one of the two files
required to implement the official mapping as described in section 3.13
of the Unicode standard version 4.0.

That section actually does specify "Simple Casing" as opposed
to the "Full Casing", however both are still required to use the
many<->many codepoint mappings from SpecialCasing.txt.  The
Simple version refers only to lack of context-sensitive special cases.

> For my applications, the case mappings defined in the draft are plenty
> useful---they're sure useful well beyond ASCII.

"Useful in some circumstances" is not grounds for tying Scheme to
a 90%, non-standardized solution.

The idea of ASCII-only mappings was suggested for the simple fact
that they are well-defined, and required for many computer formats and
protocols.  If R6RS doesn't provide them, every Scheme will in some
form or another, so it's better to standardize them.  Call them
ascii-char-ci=? etc. if the specificity bothers you.

Another possibility is to define case operations as being required
to support ASCII, with any Unicode support beyond that purely optional.

--
Alex