W3C home > Mailing lists > Public > xml-editor@w3.org > April to June 2000

Re: UTF-16BL/LE,... (was: Re: I18N issues with the XML

From: MURATA Makoto <muraw3c@attglobal.net>
Date: Thu, 13 Apr 2000 14:16:38 +0900
Message-Id: <200004130516.AA02280@t3knz.attglobal.net>
To: w3c-i18n-ig@w3.org, xml-editor@w3.org, w3c-xml-core-wg@w3.org
In message "Re: UTF-16BL/LE,... (was: Re: I18N issues with the XML",
John Cowan wrote...
 >Tim Bray scripsit:
 >> Maybe -BE and -LE really aren't UTF-16 at all.  That I can sorta kinda 
 >> believe, if I try really hard, on alternate days of the week.  Maybe there's 
 >> some situation where it's a good idea to create XML in the natural 16-bit 
 >> encoding of Unicode code points without a BOM.  That I can't believe at all.  
 >*shrug*.  If I had my way, nobody would generate any XML encoding except
 >UTF-8 and UTF-16.  That's not the Real World.  In the Real World, people
 >use any encoding for their text files that comes in handy.  The question
 >is: is there going to be a way to label those encodings properly, or not?
 >Prohibition just isn't a viable strategy: education (of the receiver,
 >who is free to reject the funny encoding) is.

I can live with UTF-16LE/BE as non-mandatory encodings.  I do not like 
XML in UTF-16LE/BE, but there are other encodings I do not like.  
I cannot find any compelling reasons to prohibit UTF-16LE/BE and allow 
other encodings.

When the charset parameter is not available, the XML processor has to 
examine encoding declarations such that each character in 
the encoding declarations are represented by two octets.  Then, other 
encodings such as Extended_UNIX_Code_Fixed_Width_for_Japanese will 
be allowed.


MURATA Makoto  muraw3c@attglobal.net
Received on Thursday, 13 April 2000 01:16:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:39 UTC