On 5 Jun 97 at 11:10, Glenn Adams wrote:
> 5. MLSF is restricted to use (i.e., defined in the context of) UTF-8 as an
> interchanged character encoding scheme (CES). As such, it is not suitable for use
> with other CESs (e.g., UTF-7 or UTF-16) and it is not suitable for use as
> a process code (internal representation) unless UTF-8 is the process code.
This is the problem for me. The MLSF proposal seems to me to
entrench UTF-8, and I have little good to say about UTF-8. It is
pretty clear from the description of UTF-8 that it was intended as a
compatibility measure for file systems that for whatever reasons
cannot tolerate certain characters, and to allow UCS-supporting
software to accept old-style ASCII arguments (file names and the
like). I find it hard to believe that anyone is using UTF-8 as a
process code (doubtless someone will speak up :-)), and yet MLSF
would seem to require translation into some sort of internal markup
if UCS-n (or anything else except UTF-8) is used as the process code.
I fondly hope that UTF-8 will go away sooner rather than
later. Obviously not everyone agrees, but I don't like the idea of a
new standard entrenching a not-universally-popular old one.
Tony Harminc
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT