This document is being written as a mid stage progress report in the project of creating a character model for W3C specifications, to make sure that the requirements of other W3C Working Groups (and of other interested parties) are understood and can be addressed. This document itself is not intended to proceed to Proposed Recommendation and Recommendation, but will serve as the base for the document that will specify the character model.
Since [RFC 2070], [ISO 10646]/[Unicode] (hereafter denoted as UCS, Universal Character Set) has served as a common reference for character encoding in W3C specifications (see [HTML 4.0], [XML 1.0], and [CSS2]). This choice was motivated by the fact that the UCS:
* Is the only universal character repertoire available
* Covers the widest possible repertoire
* Provides a way of referencing characters independent of the encoding of a resource
* Is being updated/completed carefully
* Is widely accepted and implemented by industry. As long as data transfer on the WWW was primarily unidirectional (from server to browser), and the main purpose was rendering, the direct use of the UCS as a common reference posed no problems. However, from early on, the WWW included bi-directional data transfer (forms). Recently, purposes other than rendering are becoming more and more important. The WWW has traditionally been seen as a collection of applications exchanging data based on protocols. It can however also be seen as a single, very large application. The second view is becoming more and more important due to the following developments:
* The increase in data transfers among servers, proxies, and clients
* The increase in places where non-ASCII characters are allowed
* The increase in data transfers between different protocol/format elements (such as element/attribute names, URI components, and textual content)
* Definition of specifications for APIs (as opposed to pr...