W3C home > Mailing lists > Public > www-tag@w3.org > March 2004

RE: Reviewed charmod fundamentals

From: Misha Wolf <Misha.Wolf@reuters.com>
Date: Mon, 08 Mar 2004 12:20:23 +0000
To: Julian Reschke <julian.reschke@gmx.de>, Jon Hanna <jon@hackcraft.net>
Cc: Elliotte Rusty Harold <elharo@metalab.unc.edu>, Tim Bray <tbray@textuality.com>, www-tag@w3.org
Message-id: <1987416CA83AC7499AC772F92E2DBF78BDF1BC@LONSMSXM02.emea.ime.reuters.com>

You are assuming that protocols carry documents.  Lots of 
protocols carry small discrete snippets of text in separate 
'fields'.  In such cases, there seems no point in allowing 
multiple encodings.


-----Original Message-----
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf
Of Julian Reschke
Sent: 08 March 2004 12:10
To: Jon Hanna
Cc: Elliotte Rusty Harold; Tim Bray; www-tag@w3.org
Subject: Re: Reviewed charmod fundamentals

Jon Hanna wrote:

> Quoting Elliotte Rusty Harold <elharo@metalab.unc.edu>:
> ...
> However I agree with Tim's argument that allowing a choice of UTF-8 or
UTF-16 to
> be made by an author or producing application (and hence mandating
that the two
> be differentiated and handled by the consuming application) is a good
> and should be allowed by the charmod rules.

As far as I understand, UTF-16 may perform (in terms of size) much 
better for asian languages, so it seems that it makes a lot of sense if 
protocols can choose UTF-8 vs UTF-16 based on what makes most sense for 
the document content.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.
Received on Monday, 8 March 2004 07:20:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:41 UTC