Cart
[Home] [By Thread] [By Date] [Recent Entries]
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 jcowan@r... 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."
|
