Re: The myth of the clean slate (was Re: a discussion proposal for addressing 'the character entity problem')

Rick Jelliffe scripsit:

>  1) There is no need to tie the naming proposal to a specific encoding 
> (UTF-8), and good reason (i.e. real-life usefulness) to broaded it.

I think that UTF-8 is sufficient, though I wouldn't object to a parallel
proposal for UTF-16+names.  There are people for whom UTF-16 makes much
more sense than UTF-8, and there is no reason why they shouldn't have
access to names as well.

>  2) There is no need to tie the naming proposal to specific mime types
> (*/xml*), and good reason (i.e. other text formats need convenient 
> characters just as much as XML) to broaden it.

It isn't in any way tied to XML, though it does borrow a bit of XML
syntax (and why not?).

>  3) There is no need to insist on particular delimiters, and if
> the need is recognized as being larger than for XML, good reason
> not to.

Why so?  Since the delimiters are filtered out, and there is a very
simple way to write an & character when you need to, what does it
matter what the upper-level syntax is?  This is something about XText
I never understood.

>  4) It is a mistake to introduce a superencoded reference system
> in which simple transcoding a file from UTF-8 to something else would
> render the file non-standard. When I open a UTF-8+Names file, edit
> it (as Unicode or maybe ASCII) in my editor, then save it as
> UTF-16, I have no way of labelling what encoding the file it in.

Okay, so you need UTF-16+names for that.

> The infrastructure is not set up to handle this kind of hack.

Frankly, the infrastructure isn't set up to handle character encodings
at all.

-- 
John Cowan      http://www.reutershealth.com
    "Mr. Lane, if you ever wish anything that I can do, all you will have
        to do will be to send me a telegram asking and it will be done."
    "Mr. Hearst, if you ever get a telegram from me asking you to do
        anything, you can put the telegram down as a forgery."