W3C home > Mailing lists > Public > www-html@w3.org > October 2003

Re: allow UTF-16 not just UTF-8 (PR#6774)

From: Steven Pemberton <steven.pemberton@cwi.nl>
Date: Thu, 16 Oct 2003 01:26:24 +0200
Message-ID: <162601c39373$c0f66080$df13fea9@srx41p>
To: <don@lexmark.com>
Cc: "BIGELOW,JIM (HP-Boise,ex1)" <jim.bigelow@hp.com>, <w3c-html-wg@w3.org>, <don@lexmark.com>, <voyager-issues@mn.aptest.com>, <elliott.bradshaw@zoran.com>, <www-html@w3.org>

But support for UTF 16 adds a few dozen bytes of code, and no extra memory
requirements. It is simpler than UTF 8! What's the problem?


----- Original Message ----- 
From: <don@lexmark.com>
To: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
Cc: "BIGELOW,JIM (HP-Boise,ex1)" <jim.bigelow@hp.com>; <w3c-html-wg@w3.org>;
<don@lexmark.com>; <voyager-issues@mn.aptest.com>;
<elliott.bradshaw@zoran.com>; <www-html@w3.org>
Sent: Thursday, October 16, 2003 12:20 AM
Subject: Re: allow UTF-16 not just UTF-8 (PR#6774)

> Steven, et al:
> The real problem is that the entire XML architecture was designed assuming
> high end boxes like the 3 GHz Pentium with 512 megabytes of memory.  We
> have already seen push back in other standards groups that consumer
> electronic devices and other smaller, lighter devices cannot afford all
> luxuries demand by an obese XML architecture.  Unless the XML community
> accepts subsetting, we can't expect the broadest support for XML to happen
> at the low end until the price/performance ratios experience another order
> or two magnitude improvement.  As recently reported in several of the
> magazines focused on IT professionals, the deployment of XML and Web
> Services are have significant negative impacts on the IT infrastructure
> especially in the area of bandwidth utilization.  This is just another
> symptom of the same problem.
> I know I will lose this argument in the W3C but the realities of the
> XHTML-Print implementations will blow off UTF-16 as more fat with no
> benefit and simply not support it, "interoperable" or not.
> Sorry I'm not pure but practical.
> *******************************************
> Don Wright                 don@lexmark.com
> Chair,  IEEE SA Standards Board
> Member, IEEE-ISTO Board of Directors
> f.wright@ieee.org / f.wright@computer.org
> Director, Alliances and Standards
> Lexmark International
> 740 New Circle Rd C14/082-3
> Lexington, Ky 40550
> 859-825-4808 (phone) 603-963-8352 (fax)
> *******************************************
> "Steven Pemberton" <Steven.Pemberton@cwi.nl> on 10/15/2003 09:18:15 AM
> To:    "BIGELOW,JIM \(HP-Boise,ex1\)" <jim.bigelow@hp.com>,
>        <w3c-html-wg@w3.org>, <don@lexmark.com>
> cc:    <voyager-issues@mn.aptest.com>, <elliott.bradshaw@zoran.com>,
>        <www-html@w3.org>
> Subject:    Re: allow UTF-16 not just UTF-8 (PR#6774)
> > From: don@lexmark.com [mailto:don@lexmark.com]
> > So let me understand this....
> >
> > Because people have poorly designed and written XML applications running
> on
> > 3 GHz Pentium 4s with 512 megabytes of real memory that do not allow the
> > control over whether UTF-8 or UTF-16 are emitted, we are expecting to
> burden
> > $49 printers with code to be able to detect and interpret both.
> No Don. It is about interoperability and conforming to standards. XML
> allows
> documents to be encoded in either UTF8 or UTF 16: consumers must accept
> both, producers may produce either. An XHTML-Print printer will be just a
> consumer of an XML byte-stream at some IP address; we don't want to burden
> every program in the world that can produce XML with a switch that says
> "this output is going to a poor lowly XHTML Print processor that can't
> with UTF-16, so please produce UTF-8", especially since UTF 16 is the easy
> one to implement, and can only cost a few dozen bytes at best.
> If we changed this, XHTML Print would have to go back to last call, and
> can bet your boots that the XML community would rise up against us, as it
> has in the past, and I can tell you we don't want to go there, and we
> have a hundred people registering objections.
> Conforming to XML requirements comes with the territory of being XHTML.
> XML community will not take lightly to us messing with their standards.
> Best wishes,
> Steven Pemberton
Received on Wednesday, 15 October 2003 19:27:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:05 UTC