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 the
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 trade
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 deal
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 you
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 would
have a hundred people registering objections.

Conforming to XML requirements comes with the territory of being XHTML. The
XML community will not take lightly to us messing with their standards.

Best wishes,

Steven Pemberton

Received on Wednesday, 15 October 2003 18:23:11 UTC