3.1 Perceptions of Characters
3.1.1 Introduction
The word character is used in many contexts, with different
meanings. Human cultures have radically differing writing systems, leading to
radically differing concepts of a character. Such wide variation in end user
experience can, and often does, result in misunderstanding. This variation is
sometimes mistakenly seen as the consequence of imperfect technology. Instead,
it derives from the great flexibility and creativity of the human mind and the
long tradition of writing as an important part of the human cultural
heritage.
The developers of W3C specifications, and the developers of software based
on those specifications, are likely to be more familiar with usages they have
experienced and less familiar with the wide variety of usages in an
international context. Furthermore, within a computing context, characters are
often confused with related concepts, resulting in incomplete or inappropriate
specifications and software.
This section examines some of these contexts, meanings and confusions.
3.1.2 Units of a Writing System, and Units
of Aural Rendering
The glossary entry in [Unicode 3.0] gives:
Character. (1) The smallest component of written language that has
semantic values; refers to the abstract meaning and or shape ...
In some scripts, characters have a close relationship to phonemes,
while in others they are closely related to meanings. Even when characters
(loosely) correspond to phonemes, this relationship may not be simple, and
there is rarely a one-to-one correspondence between character and phoneme.
Example: Japanese Hiragana and Katakana are syllabaries, not phonemic
alphabets. A character in these scripts corresponds not to a phoneme, but to
a syllable.
Example: Korean Hangul combines symbols for phonemes into square syllabic
blocks. Depending on the user and the application, either the individual
symbols or the syllabic clusters can be considered to be characters.
Example: Indic scripts use semi-regular or irregular ways to combine
consonants and vowels into clusters. Depending on the user and the
application, either individual consonants or vowels, or the consonant or
consonant-vowel clusters can be perceived as characters.
Specification writers and software developers MUST NOT assume that there is
a one-to-one correspondence between characters and phonemes.
3.1.3 Units of Visual
Rendering
Visual rendering introduces the notion of a glyph. Glyphs can be
defined as components used to generate the visible representation of
characters. There is not a one-to-one correspondence between
characters and glyphs:
- A single character can be represented by multiple glyphs (each glyph is
then part of the representation of that character). These glyphs may be
physically separated from one another.
- A single glyph may represent multiple characters (this is the case with
ligatures, among others).
- A character may be rendered with very different glyphs depending on the
context.
A set of glyphs makes up a font. Glyphs can be construed as the
basic units of organization of the visual rendering of text, just as
characters are the basic unit of organization of encoded text.
See Appendix A for examples of the
complexities of character to glyph mapping.
Specification writers and software developers MUST NOT assume a one-to-one
mapping between character codes and units of displayed text.
Some scripts, in particular Arabic and Hebrew, are written from right to
left. Text including characters from these scripts can run in both directions
and is therefore called bidirectional text (see examples A.6 to A.8).
[Unicode] requires that characters are stored and
interchanged in logical order. Protocols, data formats and APIs MUST store,
interchange or process text data in logical order. Where protocols or APIs
support selection, they MUST support logical selection (range of character
offsets), and they SHOULD support visual selection (area on display), because
many users prefer visual selection. Visual selection can give rise to
discontiguous logical selections and vice versa (see examples A.6 to A.8).
Protocols and APIs that specify selection MUST be able to specify
discontiguous logical selections.
3.1.4 Units of Input
In keyboard input, it is not the case that keystrokes and
input characters correspond one-to-one. A limited number of keys can fit on a
keyboard and many writing systems have too many characters to allow such a
correspondence and must rely on more complex input methods, which
transform keystroke sequences into character sequences. Other languages may
make it necessary to input some characters with special modifier keys. See Appendix A for examples of non-trivial input.
Specification writers and software developers MUST NOT assume that a single
keystroke results in a single character, nor that a single character can be
input with a single keystroke (even with modifiers), nor that keyboards are
the same all over the world.
3.1.5 Units of Collation
What a user considers a "letter" is dependent on the script or language in
question.
Example: The letter "ö" is considered as a modified "o" in French, as an
extra character quite related to "o" in German and as a character completely
independent from "o" in Swedish.
Even though software fundamentally works on the level of encoded
characters, the capabilities of software to sort (or otherwise process) text
MUST NOT be restricted to those letters that have a one-to-one relation to
encoded characters.
String comparison can both aggregate a character sequence into a single
collation unit with its own position in the sorting order, and can separate
various aspects of a character to be sorted separately.
Example: In traditional Spanish sorting, the character sequences "ch" and
"ll" are treated as atomic collation units. Although Spanish sorting, and to
some extent Spanish everyday use, treat "ch" as a character, digital encodings
treat it as two characters, and keyboards do the same.
Example: The sorting of text written in a bicameral script (i.e. a script
which has distinct upper and lower case letters) is usually required to ignore
case differences in a first pass; case then is used to break ties in a later
pass.
Software developers MUST NOT merely use a one-to-one mapping as their
string-compare function, as in sorting operations.
3.1.6 Units of Storage
Computer storage and communication rely on units of physical storage and
information interchange, such as bits and bytes (also known as octets). A
frequent error in specifications and implementations is the equating of
characters with units of physical storage. The mapping between characters and
such units of storage is actually quite complex, and is discussed in the next
section, 3.2 Digital Representation of
Characters.
Specification writers and software developers MUST NOT assume a simple
relationship between characters and units of physical storage. Depending on
the circumstances, this relationship may be many-to-many, one-to-many,
many-to-one, or one-to-one.
3.1.7 Summary
The term character is used differently in a variety of contexts
and often leads to confusion when used outside of these contexts. In the
context of the digital representations of text, a character can be defined
informally as a small logical unit of text. Text is then defined as sequences
of characters. While such an informal definition is sufficient to create or
capture a common understanding in many cases, it is also sufficiently open to
create misunderstandings as soon as details start to matter. In order to
write effective specifications, protocol implementations, and software for end
users, it is very important to understand that these misunderstandings can
occur.
Specifications using the term character MUST specify which of the
possible meanings they intend. Specifications SHOULD avoid the use of the
term character if a more specific term is available.
3.2 Digital Representation of Characters
To be of any use in computers, in computer communications and in particular
on the World Wide Web, characters must be encoded. In fact, much of the
information processed by computers over the last few decades has been encoded
text, exceptions being images, audio, video and numeric data. To achieve text
encoding, a large variety of encoding schemes have been devised, which can
loosely be defined as mappings between the character sequences that users
manipulate and the sequences of bits that computers manipulate.
Given the complexity of text encoding and the large variety of schemes for
character encoding invented throughout the computer age, a more formal
description of the encoding process is useful. Text encoding can be described
as follows (see [UTR #17] for a more detailed
description):
A set of characters to be encoded is
identified. The units of encoding, the characters, are pragmatically
chosen to express text and to efficiently allow various text processes in
one or more target languages. They may not correspond precisely to what
users perceive as letters and other characters. The set of characters is
called a repertoire.
Each character in the repertoire is then
associated with a (mathematical, abstract) non-negative integer, the
code point (also known as a character number). The
result, a mapping from the repertoire to the set of non-negative integers,
is called a coded character set (CCS).
To enable use in computers, a suitable base
datatype is identified (such as a byte, a 16-bit wyde or other) and a
character encoding form (CEF) is used, which encodes the abstract
integers of a CCS into sequences of the code units of the base
datatype. The encoding form can be extremely simple (for instance, one
which encodes the integers of the CCS into the natural representation of
integers of the chosen datatype of the computing platform) or arbitrarily
complex (a variable number of code units, where the value of each unit is
a non-trivial function of the encoded integer).
To enable transmission or storage using
byte-oriented devices, a serialization scheme or character
encoding scheme (CES) is next used. A CES maps the integers of one or
more CCSes to well-defined sequences of bytes, taking into account the
necessary specification of byte-order for multi-byte base datatypes and
including in some cases switching schemes between multiple CCSes (an
example is ISO 2022). A CES, together with the CCSes it is used with, is
identified by an IANA
charset identifier. Given a sequence of bytes representing
text and a charset identifier, one can in principle
unambiguously recover the sequence of characters of the text.
Note: Unfortunately, there are some important cases of charset
identifiers that denote a range of slight variants of an encoding scheme,
where the differences may be crucial (e.g. the well-known yen/backslash case)
and may vary over time. In those cases, recovery of the character sequence
from a byte sequence is not totally unambiguous. See the [XML Japanese profile] for examples of such
ambiguous charsets.
In very simple cases, the whole encoding process can be collapsed to a
single step, a trivial one-to-one mapping from characters to bytes; this is
the case, for instance, for US-ASCII and ISO 8859-1.
3.3 Transcoding
Transcoding is the process of converting text data from one Character Encoding Form to another. Transcoders work only
at the level of character encoding and do not parse the text; consequently,
they do not deal with character escapes such as numeric character references
(see 3.7 Character Escaping) and do not fix up
embedded charset information (for instance in an XML declaration or in an HTML
<meta> element).
Note: Transcoding may involve one-to-one, many-to-one, one-to-many or
many-to-many mappings. Because some legacy mappings are glyphic, they may not
only be many-to-many, but also discontinuous: thus XYZ may map to yxz. See
example A.5.
A normalizing-transcoder
is a transcoder that converts from a legacy encoding to a Unicode encoding
form and ensures that the result is in Unicode Normalization
Form C (see 4.2.1 Unicode-normalized
Text).
3.4 Strings
Various specifications use the notion of a string, sometimes
without defining precisely what is meant and sometimes defining it differently
from other specifications. The reason for this variability is that there are
in fact multiple reasonable definitions for a string, depending on one's
intended use of the notion. This section provides a few definitions which may
be reused elsewhere.
Byte string: A byte
string is a sequence of bytes representing characters in a particular
encoding. This corresponds to a CES. As a definition
for a string, this definition is most often useless, except when the textual
nature is unimportant and the string is considered only as a piece of opaque
data with a length in bytes. Specifications in general SHOULD NOT define a
string as a byte string.
Physical string: A
physical string is a sequence of code units representing characters
in a particular encoding. This corresponds to a CEF.
This definition is useful in APIs that expose a physical representation of
string data. Example: For the [DOM Level 1], UTF-16 was
chosen based on widespread implementation practice.
Character string: A
character string is a sequence of characters, each represented by a
code point in [Unicode]. This is usually what
programmers consider to be a string, although it does not match exactly the
user perception of characters. This is the highest layer of abstraction that
ensures interoperability with very low implementation effort. This definition
is generally the most useful and SHOULD be used by most specifications,
following the examples of Production [2] of [XML 1.0], the SGML declaration of
[HTML 4.01], and the character model of [RFC 2070].
Grapheme string: A
grapheme string is a sequence of character clusters, where the
clusters are defined to be as close as possible to what the user perceives as
characters, but in a way that is still language-independent.
Language-dependent
grapheme string: A language-dependent grapheme string is a
sequence of character clusters, where the clusters are defined to be as close
as possible to what the user perceives as characters, taking into account
language dependencies.
The first three definitions directly correspond to digital representation
of characters as described in Section 3.2. The grapheme strings do not have a
direct equivalent since they represent sequences of digital representations of
characters. Widely accepted definitions of this clustering do not currently
exist, but information about many aspects of it is provided in Chapter 5,
Implementation Guidelines, of [Unicode 3.0],
and in several Unicode Technical Reports.
3.5 Reference Processing Model
Many Internet protocols and data formats, most notably the very important
Web formats HTML, CSS and XML, are based on text. In those formats, everything
is text but the relevant specifications impose a structure on the text, giving
meaning to certain constructs so as to obtain functionality in addition to
that provided by plain text. HTML and XML are markup languages,
defining entities entirely composed of text but with conventions allowing the
separation of this text into markup and character data. Citing
from [XML 1.0], section 2.4:
Text consists of intermingled character data and markup.
[...] All text that is not markup constitutes the character data of the
document.
For the purposes of this section, the important aspect is that everything
is text, that is, a sequence of characters.
Since its early days, the Web has seen the development of a Reference
Processing Model. This model was first adopted for HTML and later embraced
by XML and CSS. It is applicable to any data format or protocol that is
text-based as described above. The essence of the Reference Processing Model
is the use of Unicode as a common reference. For a specification to use the
Reference Processing Model does not require that implementations
actually use Unicode. The requirement is only that the implementations behave
as if the processing took place as described by the Model.
A specification conforms to the Reference Processing Model if all of the
following apply:
- The specification MUST be defined in terms of Unicode characters, not
bytes or glyphs.
- The specification MUST NOT arbitrarily restrict the range of characters
that can be used, which must cover all Unicode code points from 0 to
0x10FFFF inclusive.
- The specification MAY allow use of any character encoding which can be
transcoded to Unicode for its text entities. It MAY choose to disallow or
deprecate some encodings and to make others mandatory. Independent of the
actual encoding, the specified behavior MUST be the same as if the
processing happened as follows:
- the encoding of any text entity received by the application
implementing the specification MUST be determined and the text entity
MUST be interpreted as a sequence of Unicode characters. This MUST be
equivalent to transcoding the entity to some Unicode encoding form and
receiving it in that encoding form;
- all processing MUST take place on this sequence of Unicode
characters;
- if text is output by the application, the sequence of Unicode
characters MUST be encoded using an encoding chosen among those
allowed by the specification.
- If the specification is such that multiple text entities are involved
(such as an XML document referring to external parsed entities), it MAY
choose to allow these entities to be in different character encodings. In
all cases, this Reference Processing Model MUST be applied to all
entities.
Unless there are strong reasons to do otherwise, all W3C specifications
that involve text SHOULD specify conformance to the Reference Processing
Model. To ensure interoperability, all specifications SHOULD also require
conformance to section 4 Early Uniform
Normalization.
Note: All specifications that derive from [XML 1.0]
automatically inherit this Reference Processing Model. XML is entirely defined
in terms of Unicode characters and mandates the UTF-8 and UTF-16 encodings
while allowing any other encoding for parsed entities.
Note: When specifications choose to allow encodings other than Unicode
encodings, implementers should be aware that the correspondence between the
characters of a legacy encoding and Unicode characters may in practice depend
on the software used for transcoding. See the [XML Japanese profile] for examples of such
inconsistencies.
3.6 Choice and Identification of Character
Encodings
Because encoded text cannot be interpreted and processed without
knowing the encoding, it is vitally important that the character encoding is
known at all times and places where text is exchanged or processed.
Specifications MUST either specify a unique encoding, or provide mechanisms
such that the encoding of text is always reliably identified. When designing a
new protocol, format or API, specifications SHOULD mandate a unique character
encoding.
Mandating a unique character encoding is simple, efficient, and robust.
There is no need for specifying, producing, transmitting, and interpreting
encoding tags. At the receiver, the encoding will always be understood. There
is also no ambiguity if data is transferred non-electronically and later has
to be converted back to a digital representation. Even when there is a need
for compatibility with existing data, systems, protocols and applications,
multiple encodings can often be dealt with at the boundaries or outside a
protocol, format, or API. The DOM ([DOM Level 1]) is an
example of where this was done. The advantages of choosing a unique encoding
become more important the smaller the pieces of text used are and the closer
to actual processing the specification is.
When a unique encoding is mandated, the encoding MUST be UTF-8 or UTF-16.
If compatibility with ASCII is desired, UTF-8 (see [RFC
2279]) is RECOMMENDED; on the Internet, the IETF Charset Policy [RFC 2277] specifies that "Protocols MUST be able to use
the UTF-8 charset". For APIs, UTF-16 (see [RFC 2781])
is more appropriate.
3.6.1 Character Encoding Identification
If the unique encoding approach is not chosen, then protocols MUST provide
for character encoding identification which SHOULD be along the lines of the
[MIME] Internet specification. The MIME charset
parameter is defined such that it provides sufficient information to
unambiguously decode the sequence of bytes of the payload into a sequence of
characters. The values are drawn from the IANA charset registry [IANA].
Note: The term charset derives from "character set", an expression
with a long and tortured history (see [Connolly] for a
discussion). Specifications SHOULD avoid using the expression "character set",
as well as the term "charset", except when the latter is used to refer to the
MIME charset parameter or its IANA-registered values. The terms
character encoding or character encoding scheme are
recommended.
The IANA charset registry is the official list of names and aliases
for character encodings on the Internet. If the unique encoding approach is
not taken, specifications SHOULD mandate the use of those names, and in
particular the names labeled in the registry as MIME preferred names,
to designate character encodings in protocols, data formats and APIs. The "x-"
convention for unregistered names SHOULD NOT be used, having led to abuse in
the past (use of "x-" for character encodings that were widely used, even long
after there was an official registration). Content developers and software
that tags textual data MUST use one of the names mandated by the appropriate
specification (e.g. the XML specification when editing XML text) and SHOULD
use the MIME preferred name of an encoding to tag data in that encoding. An
IANA-registered charset name MUST NOT be used to tag textual data in an
encoding other than the one identified in the IANA registration of that
name.
If the unique encoding approach is not chosen, specifications MUST
designate at least one of the UTF-8 and UTF-16 encoding forms of Unicode as
admissible encodings and SHOULD choose at least one of UTF-8 or UTF-16 as
mandated encoding forms (encoding forms that MUST be supported by
implementations of the specification). They MAY define either UTF-8 or UTF-16
as a default (or both if they define suitable means of distinguishing them),
but they MUST NOT use any other character encoding as a default. Also, they
MUST avoid reliance on unreliable heuristics.
Receiving software MUST determine the encoding from available
information. It MAY recognize as many encodings (names and aliases) as
appropriate. A field-upgradeable mechanism may be appropriate for this
purpose. When a IANA-registered charset name is recognized, receiving
software MUST interpret the received data according to the encoding associated
with the name in the IANA registry. When no charset is provided the receiving
software MUST adhere to the default encoding(s) specified in the
specification.
Certain encodings are more or less associated with certain languages
(e.g. Shift-JIS with Japanese); trying to support a given language or
set of customers may mean that certain encodings have to be supported. The
encodings that need to be supported may change over time. This document does
not give any advice on which encoding may be appropriate or necessary for the
support of any given language.
Implementers of software MUST fully support character encoding
identification mechanisms and SHOULD make it easy to use them (for instance in
HTTP servers). On interfaces to other protocols, implementers SHOULD support
conversion between Unicode encoding forms as well as any other necessary
conversions. Content developers MUST make use of the offered facilities by
always indicating character encoding.
Because of the layered Web architecture (e.g. formats used over protocols),
there may be multiple and at times conflicting information about character
encoding. Specifications MUST define conflict-resolution mechanisms
(e.g. priorities) for these cases, and implementers and content
developers MUST follow them carefully.
3.6.2 Private Use Code Points
Unicode designates certain ranges of code points for private use: the
Private Use Area (U+E000-F8FF) and planes 15 and 16 (U+F0000-FFFFD and
U+100000-10FFFD). These code points are guaranteed to never be allocated to
standard characters, and are available for use by private agreement between a
producer and a recipient. However, their use is strongly discouraged, since
private agreements do not scale on the Web. Code points from different private
agreements may collide, and a private agreement and therefore the meaning of
the code points can quickly get lost.
Specifications MUST NOT define any assignments of private use code points,
and MUST NOT rely on any assignments to private use code points by other
parties. Specifications MUST NOT provide mechanisms for private agreement
between parties. Specifications and implementations SHOULD be designed in such
a way as to not disallow the use of these code points by private arrangement.
As an example, XML does not disallow the use of private use code points.
Where specifications need to allow the transmission of symbols not in
Unicode or need to identify specific variants of Unicode characters, they MAY
define markup for this purpose.
Example: [SVG], in section
10.14, defines an element altGlyph which allows the
identification of specific display variants of Unicode characters.
3.7 Character Escaping
In text-based protocols or formats where characters can be either part of
character data or of markup (cf. 3.5 Reference
Processing Model), it is often the case that certain characters are
designated as having certain specific protocol/format functions in certain
contexts (e.g. "<" and "&" serve as markup delimiters in HTML and XML).
These syntactically relevant characters cannot be used to represent themselves
in text data in the same way as all other characters do. Also, often formats
are represented in an encoding that does not allow to represent all characters
directly.
To express syntactically relevant or unrepresentable characters, a
technique called escaping is used. This works by creating an
additional syntactic construct, defining additional characters or defining
character sequences that have special meaning. Escaping a character means
expressing it using such a construct, appropriate to the format or protocol in
which the character appears; expanding an escape (or unescaping)
means replacing it with the character that it represents.
Certain guidelines apply to the way specifications define character
escapes. These guidelines MUST be followed when designing new W3C protocols
and formats and SHOULD be followed as much as possible when revising existing
protocols and formats.
- Specifications MUST NOT invent a new escaping mechanism if an
appropriate one already exists.
- There SHOULD be only one way to escape a character. [A well-known
counter-example is that for historical reasons, both HTML and XML have
redundant decimal (&#ddddd;) and hexadecimal (&#xhhhh;)
escapes.]
- Explicit end delimiters MUST be provided. Escapes such as \uABCD where
the end delimiter is a space or any character other than [01-9A-F] SHOULD
be avoided: it is not clear visually, and it can cause an editor to insert
spurious line-breaks when word-wrapping on spaces. Forms like SPREAD's
&UABCD; [SPREAD] or XML's &#xhhhh;, where
the escape is explicitly terminated by a semicolon, are much better.
Escaped characters SHOULD be acceptable wherever unescaped characters are.
In particular, they SHOULD be acceptable in identifiers and comments.
4 Early Uniform Normalization
4.1 Motivation
As explained at length in Requirements for String Identity Matching
and String Indexing [CharReq], the existence, in
many character encoding schemes, of multiple representations for what users
perceive as the same string makes it necessary to define character data
normalization. Without a precise specification, it is not possible to
determine reliably whether or not two strings are identical. Such a
specification must take into account character encoding, the way to perform
normalization and where or when to perform it.
The Unicode Consortium provides four standard normalization forms (see
Unicode Normalization Forms [UTR #15]). For use on the
Web, this document defines W3C Text Normalization by picking the most
appropriate of these (NFC) and additionally addressing the issues of legacy
encodings and of character escapes (which can denormalize text when
unescaped).
This document also specifies that normalization is to be performed
early (by the sender) as opposed to late (by the recipient). The
reasons for that choice are manifold:
Almost all legacy data as well as data created by current software is
normalized (using NFC).
The number of Web components that generate or transform text is
considerably smaller than the number of components that receive text and
need to perform matching or other processes requiring normalized text.
Current receiving components (browsers, XML parsers, etc.) implicitly
assume early normalization by not performing normalization themselves.
This is a vast legacy.
Web components that generate and process text are in a much better
position to do normalization than other components; in particular, they
may be aware that they deal with a restricted repertoire only.
Not all components of the Web that implement functions such as string
matching can reasonably be expected to do normalization. This, in
particular, applies to very small components and components in the lower
layers of the architecture.
Forward-compatibility issues can be dealt with more easily: less
software needs to be updated, namely only the software that generates
newly introduced characters.
It improves matching in cases where the character encoding is partly
undefined, such as URIs [RFC 2396].
It is a prerequisite for comparison of encrypted strings (see [CharReq], section 2.7).
It simplifies definitions and implementations for string indexing
(see [CharReq], section 4.6).
It increases interoperability and predictability when string data is
exposed in an API.
4.2 Definitions for W3C Text
Normalization
4.2.1 Unicode-normalized Text
Text data is, for the purposes of this specification,
Unicode-normalized if it is in a Unicode encoding form
and is in Unicode Normalization Form C (according to revision
18 of [UTR #15]).
4.2.2 W3C-normalized Text
Text data is W3C-normalized (normalized for short)
if:
it is Unicode-normalized and does not contain any
character escapes whose unescaping would cause the data to become no
longer Unicode-normalized; or
it is in a legacy encoding and, after transcoding by
a normalizing-transcoder, is
W3C-normalized.
Note: Legacy text is always normalized unless it contains escapes which,
once expanded, denormalize it.
Note: W3C-normalization is specified against the context of a markup
language (or the absence thereof), which specifies the form of escapes. For
plain text (no escapes) in a Unicode encoding form, W3C-normalization and
Unicode-normalization are equivalent.
4.2.3 Examples
The string "suçon", expressed as the sequence of five characters U+0073
U+0075 U+00E7 U+006F U+006E and encoded in a Unicode encoding form, is both
Unicode-normalized and W3C-normalized. The same string encoded in a legacy
encoding for which there exists a normalizing-transcoder would be
W3C-normalized but not Unicode-normalized.
The string "suçon", expressed as the sequence of six
characters U+0073 U+0075 U+0063 U+0327 U+006F U+006E (U+0327 is the
COMBINING CEDILLA) and encoded in a Unicode encoding form, is neither
W3C-normalized nor Unicode-normalized.
In an XML or HTML context, the string "suçon" is not
W3C-normalized, whatever the encoding form, because expanding "̧"
yields the sequence "suc¸on" which is not Unicode-normalized. Note that,
since Unicode-normalization doesn't take escapes into account, the string
"suçon" is Unicode-normalized if encoded in a
Unicode encoding form.
4.3 Responsibility for
Normalization
Producers MUST produce text data in normalized form. For the purpose of W3C
specifications and their implementations, the producer of text data is the
sender of the data in the case of protocols and the tool that produces the
data in the case of formats.
Note: Implementers of producer software in the above sense are encouraged
to delegate normalization to their respective data sources wherever possible.
Examples of data sources are operating systems, libraries, and keyboard
drivers.
The recipients of text data MUST assume the data is normalized and MUST NOT
normalize it. Recipients which transcode text data from a legacy encoding to a
Unicode encoding form MUST use a normalizing-transcoder.
If a software module functions as both a producer and a recipient of text
data (e.g. a browser/editor), normalization MUST be applied in the
producer part but MUST NOT be applied in the recipient part.
Note: The prohibition of normalization by recipients is necessary for
consistency, on which security depends. As an example of a security
vulnerability, an XML document containing two elements whose names differ only
in their normalization state would be interpreted differently by processes
that do or do not normalize received text. The only secure alternative to
this prohibition would be late normalization, where all recipients have to
normalize all the time.
Intermediate (recipient/producer) components whose role involves
modification of text data MUST ensure that their modifications do not result
in denormalization of the data. Consequently, any modification (addition,
deletion, etc.) MUST be followed by normalization of the affected text region
(which includes the characters neighboring the modification point) or,
OPTIONALLY, of the entire text data.
Example: If the "z" is deleted from the (normalized) string "cz¸" (where
"¸" represents a combining cedilla, U+0327), normalization is necessary to
turn the denormalized result "c¸" into the properly normalized "ç". Analogous
cases exist for addition and concatenation.
As an optimization, the normalization operations made necessary by
modifications MAY be deferred until the text needs to be exposed (sent on the
network, saved to disk, returned in an API call, etc.)
Intermediate components whose role does not involve modification of the
data (e.g. caching proxies) MUST NOT perform normalization.
5 Compatibility and Formatting
Characters
This specification does not address the suitability of particular
characters for use in markup languages, in particular formatting characters
and compatibility equivalents. For detailed recommendations about the use of
compatibility and formatting characters, see [UXML].
Specifications SHOULD exclude compatibility characters in the syntactic
elements (markup, delimiters, identifiers) of the formats they define (e.g.
exclusion of compatibility characters for GIs in XML).
This specification does not address any further equivalents, such as case
equivalents, the equivalence between katakana and hiragana, the equivalence
between accented and un-accented characters, the equivalence between full
characters and fallbacks (e.g., "ö" vs. "oe" in German), and the equivalence
between various spellings (e.g., color vs. colour). Such equivalences are on
a higher level; whether and where they are needed depends on the language, the
application, and the preferences of the user.
6 String Identity Matching
One important operation that depends on early normalization is string
identity matching [CharReq], which is a subset of
the more general problem of string matching. There are various degrees of
specificity for string matching, from approximate matching such as regular
expressions or phonetic matching, to more specific matches such as
case-insensitive or accent-insensitive matching and finally to identity
matching. In the Web environment, where multiple encodings are used to
represent strings, including some encodings which allow multiple
representations for the same thing, identity is defined to occur if and only
if the compared strings contain no user-identifiable distinctions. This
definition allows strings to match when they differ only in their encodings
(including escapes) or when strings in the same encoding differ only by their
use of precomposed and decomposed character sequences, yet does not make
equivalent strings that differ in case or accentuation.
To avoid unnecessary conversions and, more importantly, to ensure
predictability, all components of the Web must use the same identity testing
mechanism. To meet this requirement and support the above definition of
identity, this specification mandates the following steps for string identity
matching:
Early uniform normalization to W3C-normalized form, as defined in 4.2.2 W3C-normalized Text
Conversion to a common encoding of UCS, if necessary
Expansion of all escapes
Binary comparison
In accordance with section 4 Early Uniform
Normalization, the first step MUST be performed by the
producers of the strings to be compared. This ensures 1) that
the identity matching process can produce correct results using the next three
steps and 2) that a minimum of effort is spent on solving the problem.
7 String Indexing
There are many situations where a software process needs to access a
substring or to point within a string and does so by the use of indices, i.e.
numeric "positions" within a string. Where such indices are exchanged between
components of the Web, there is a need for an agreed-upon definition of string
indexing in order to ensure consistent behavior. The requirements for string
indexing are discussed in [CharReq], section 4. The two main questions
that arise are: "What is the unit of counting?" and "Do we start counting at 0
or 1?".
Depending on the particular requirements of a process, the unit of counting
may correspond to any of the definitions of a string provided in section 3.4 Strings (which all follow the pattern "a
<foo string> is a sequence of <unit>s"). In
particular:
- Character string is RECOMMENDED.
(Example: [XPath])
- Physical string MAY be used if the
choice of character string would severely impact the efficiency of
internal operations. (Example: use of UTF-16 in [DOM Level
1]).
- Grapheme string will become a good
option where user interaction is the primary concern, once a definition
for it is widely accepted.
It is noteworthy that there exist other, non-numeric ways of identifying
substrings which have favorable properties. For instance, substrings based on
string matching are quite robust against small edits; substrings based on
document structure (in structured formats such as XML) are even more robust
against edits and even against translation of a document from one language to
another. Consequently, specifications that need a way to identify substrings
or point within a string SHOULD provide ways other than string indexing to
perform this operation. Users of such specifications (software developers,
content developers) SHOULD prefer those other ways whenever possible.
Experience shows that more general, flexible and robust specifications
result when individual characters are understood and processed as substrings,
identified by a position before and a position after the substring.
Understanding indices as boundary positions between the
counting units also makes it easier to relate the indices resulting from the
different string definitions. Specifications SHOULD use this form of indexing,
regardless of the choice of counting units. APIs in addition SHOULD NOT
specify single character or single encoding-unit arguments.
The issue of index origin, i.e. whether we count from 0 or 1, actually
arises only after a decision has been made on whether it is the units
themselves that are counted or the positions between the units. With the
latter, starting with an index of 0 for the position at the start of the
string is the RECOMMENDED solution, with the last index then being equal to
the number of counting units in the string.
According to the definition in [RFC 2396], URI
references are restricted to a subset of US-ASCII. This RFC also specifies an
escaping mechanism to encode arbitrary byte values, using the %HH convention.
However, because the RFC does not define the mapping from characters to bytes,
the %HH convention by itself is of limited use. This chapter defines how to
address this issue in W3C specifications in a way consistent with the model
defined in this document and with deployed practice.
W3C specifications that define protocol or format elements (e.g. HTTP
headers, XML attributes,...) whose role is that they be interpreted as URI
references (or specific subsets of URI references, such as absolute URI
references, URIs,...) MUST allow these protocol or format elements to contain
characters disallowed by the URI syntax. The disallowed characters include all
non-ASCII characters, plus the excluded characters listed in Section 2.4 of [RFC 2396], except for the number sign (#) and percent
sign (%) characters and the square bracket characters re-allowed in [RFC 2732].
When passing such protocol or format elements to software components that
cannot deal with anything else than characters legal in URI references, a
conversion is needed. W3C specifications MUST define when this conversion is
to be made. The conversion MUST take place as late as possible, i.e. all
characters should be preserved as long as possible. W3C specifications MUST
specify that conversion to a URI reference is carried out as follows:
- Each disallowed character is converted to UTF-8, resulting in one or
more bytes.
- The resulting bytes are escaped using the URI escaping mechanism (that
is, each byte is converted to %HH, where HH is the byte value expressed
using hexadecimal notation).
- The original character is replaced by the resulting character
sequence.
Example: The string "http://www.w3.org/People/Dürst/" is not a legal URI
because the character "ü" is not allowed in URIs. The representation of "ü" in
UTF-8 consists of two bytes with the values 0xC3 and 0xBC. The string is
therefore converted to "http://www.w3.org/People/D%C3%BCrst/".
Note: [I-D URI-I18N] recently proposed the term
Internationalized Resource Identifiers (IRI). A future version of
this specification will adopt this term if it proves to be useful.
Request for feedback: There is currently a small but
serious difference between [I-D URI-I18N] and the
provisions above. US-ASCII characters which are not allowed in URIs (such as
space, backslash, and curly brackets) are also not allowed in IRIs, but are
allowed in protocol and format elements as defined above because they are
escaped (as described above) during the conversion a legal URI. We are
requesting feedback on how to deal with this discrepancy.
Note: The intent of this chapter is not to limit URI references to a subset
of US-ASCII characters forever, but to ensure that W3C technology correctly
and predictably interacts with systems that are based on the definition of URI
references while taking advantage of the capabilities of W3C technology to
handle the UCS repertoire.
Note: The ability to use URI references with encodings other than UTF-8 is
not affected by this chapter. However, in such a case, the %HH-escaped form
has always to be used. As an example, if the HTTP server at www.w3.org used
only ISO-8859-1, the above string, when used in a protocol or format element
defined by a W3C specification, would always have to be given in the escaped
form, "http://www.w3.org/People/D%FCrst/" ('ü' in ISO-8859-1 is 0xFC).
A W3C specification that defines new syntax for URIs, such as a new kind of
fragment identifier, MUST specify that characters outside the US-ASCII
repertoire are encoded in URIs using UTF-8 and %HH-escaping. This makes such
new syntax fully interoperable with the above provisions.
Example: [XPointer] defines fragment identifiers
for XML documents. An XPointer to an element with the ID résumé
is xpointer(id('résumé')). The resulting fragment identifier is
xpointer(id('r%C3%A9sum%C3%A9')) as the escaped UTF-8 of 'é' is
%C3%A9. A URI reference to that element in a document called
doc.xml is doc.xml#xpointer(id('r%C3%A9sum%C3%A9')). Using
[XLink], and assuming the encoding of the XML document can represent 'é'
directly, this can be written as
xlink:href="doc.xml#xpointer(id('résumé'))". This looks very
convenient and obvious, but it should be noted that it is only possible due to
the fact that the encoding is aligned between representation (in XLink href)
and interpretation (in XPointer).
9 Referencing the Unicode Standard and
ISO/IEC 10646
Specifications often need to make references to the Unicode standard or
International Standard ISO/IEC 10646. Such references must be made with care,
especially when normative. The questions to be considered are:
- Which standard should be referenced?
- How to reference a particular version?
- When to use versioned vs. unversioned references?
ISO/IEC 10646 is developed and published jointly by ISO (the International Organisation for
Standardisation) and IEC (the International
Electrotechnical Commission). The Unicode Standard is developed and published
by the Unicode Consortium, an
organization of major computer corporations, software producers, database
vendors, national governments, research institutions, international agencies,
various user groups, and interested individuals. The Unicode Standard is
comparable in standing to W3C Recommendations.
ISO/IEC 10646 and Unicode define exactly the same CCS (same repertoire,
same code points) and encoding forms. This synchronism is actively maintained
by liaisons and overlapping membership between the respective technical
committees. In addition to the jointly defined CCS and encoding forms, the
Unicode Standard adds normative and informative lists of character properties,
normative character equivalence and normalization specifications, a normative
algorithm for bidirectional text and a large amount of useful implementation
information. In short, Unicode adds semantics to the characters that ISO/IEC
10646 merely enumerates. Conformance to Unicode implies conformance to ISO/IEC
10646, see [Unicode 3.0] Appendix C.
Since specifications in general need both a definition for their characters
and the semantics associated with these characters, specifications SHOULD
include a reference to the Unicode Standard, whether or not they include a
reference to ISO/IEC 10646. By providing a reference to The Unicode Standard
implementers can benefit from the wealth of information provided in the
standard and on the Unicode Consortium Web site.
The fact that both ISO/IEC 10646 and Unicode are evolving (in synchronism)
raises the issue of versioning: should a specification refer to a specific
version of the standard, or should it make a generic reference, so that the
normative reference is to the version current at the time of reading
the specification? In general the answer is both. A generic reference
MUST be made if it is desired that characters allocated after a specification
is published are usable with that specification. A specific reference MAY be
included to ensure that functionality depending on a particular version is
available and will not change over time (an example would be the set of
characters acceptable as Name characters in [XML 1.0],
which is an enumerated list that parsers must implement to validate
names).
A generic reference to the Unicode Standard does not carry a version
number. All generic references to Unicode MUST be understood to refer
to version 3.0 or later. Generic references to ISO/IEC 10646 MUST be written
such that they make allowance for the future publication of additional
parts of the standard. They MUST be understood to refer to [ISO/IEC 10646-1:2000] or later, including any
amendments.
Whether such a reference is included in the bibliography section of a
specification, or a simpler reference with explanatory text in the body of the
specification, is an editorial matter best left to each specification.
Examples of the latter, as well as a discussion of the versioning issue with
respect to MIME charset parameters for UCS encodings, can be found in
[RFC 2279] and [RFC 2781].
Appendix A: Examples of Characters,
Keystrokes and Glyphs
A few examples will help make sense of all this complexity (which is mostly
a reflection of the complexity of human writing systems). Let us start with a
very simple example: a user, equipped with a US-English keyboard, types "Foo",
which the computer encodes as 16-bit values (the UTF-16 encoding of Unicode)
and displays on the screen.
Example A.1: Basic Latin
| Keystrokes |
Shift-f |
o |
o |
| Input characters |
F |
o |
o |
| Encoded characters (byte
values in hex) |
0x0046 |
0x006F |
0x006F |
| Display |
Foo |
The only complexity here is the use of a modifier (Shift) to input the
capital F.
A slightly more complex example is a user typing "çé" on a French-Canadian
keyboard, which the computer again encodes in UTF-16 and displays. We assume
that this particular computer uses a fully composed form of UTF-16.
Example A.2: Latin with diacritics
| Keystrokes |
¸ c |
é |
| Input characters |
ç |
é |
| Encoded characters (byte
values in hex) |
0x00E7 |
0x00E9 |
| Display |
çé |
A few interesting things are happening here: when the user types the
cedilla (¸), nothing happens except for a change of state of the keyboard
driver; the cedilla is a dead key. When the driver gets the c, it
provides a complete ç character to the system, which represents it as a single
16-bit code unit and displays a ç glyph. The user then presses the dedicated é
key, which results in, again, a character represented by two bytes. Most
systems will display this as one glyph, but it is also possible to combine two
glyphs (the base letter and the accent) to obtain the same rendering.
On to a Japanese example: our user employs an input method to type "
", which the computer
encodes in UTF-16 and displays.
Example A.3: Japanese
| Keystrokes |
n i h o n g o <space><return> |
| Input characters |
 |
 |
 |
| Encoded characters (byte
values in hex) |
0x65E5 |
0x672C |
0x8A9E |
| Display |
|
The interesting aspect here is input, where the user has to type a total of
nine keystrokes before the three characters are produced, which are then
encoded and displayed rather trivially. An Arabic example will show different
phenomena:
Example A.4: Arabic
| Keystrokes |
 |
 |
 |
 |
|
| Input characters |
|
|
|
|
|
|
| Encoded characters (byte
values in hex) |
0x0644 |
0x0627 |
0x0644 |
0x0627 |
0x0639 |
0x0639 |
| Display |
 |
Here the first two keystrokes each produce an input character and an
encoded character, but the pair is displayed as a single glyph (, a lam-alif ligature).
The next keystroke is a lam-alif, which some Arabic keyboards have; it
produces the same two characters which are displayed similarly, but this
second lam-alif is placed to the left of the first one. The last two
keystrokes produce two identical characters which are rendered by two
different glyphs (a medial form followed to its left by a final form). We thus
have 5 keystrokes producing 6 characters and 4 glyphs laid out
right-to-left.
A final example in Tamil, typed with an ISCII
keyboard, will illustrate some additional phenomena:
Example A.5: Tamil
| Keystrokes |
 |
 |
 |
 |
 |
 |
| Input characters |
|
|
|
|
|
|
| Encoded characters (byte
values in hex) |
0x0B9F |
0x0BBE |
0x0B99 |
0x0BCD |
0x0B95 |
0x0BCB |
| Display |
 |
Here input is straightforward, but note that contrary to the preceding
accented Latin example, the diacritic (virama, vowel killer) is entered
after the to which
it applies. Rendering is interesting for the last two characters. The last one
() clearly consists of two
glyphs which surround the glyph of the next to last character ().
A number of operations routinely performed on text can be impacted by the
complexities of the world's writing systems. An example is the operation of
selecting text on screen by a pointing device in a bidirectional (bidi)
context. First, let's have some bidi text, in this case Arabic letters
(written right-to-left) mixed with Arabic-Hindi digits (left-to-right):
Example A.6: Bidirectional text
| In memory |
  <space>    <space>    |
| On screen |
 |
In the presence of bidi text, two possible selection modes must be
considered. The first is logical selection mode, which selects all the
characters logically located between the end-points of the user's
mouse gesture. Here the user selects from between the first and second letters
of the second word to the middle of the number. Logical selection looks like
this:
Example A.7: Example of logical selection
| In memory |
|
| On screen |
 |
It is a consequence of the bidirectionality of the text that a single,
continuous logical selection in memory results in a discontinuous selection
appearing on the screen. This discontinuity, as well as the somewhat
unintuitive behavior of the cursor, makes many users prefer a visual
selection mode, which selects all the characters visually located
between the end-points of the user's mouse gesture. With the same mouse
gesture as before, we now obtain:
Example A.8: Example of visual selection
| In memory |
|
| On screen |
 |
In this mode, popular with users, a single visual selection range results
in two logical ranges, which MUST be accommodated by protocols, APIs and
implementations.
Special thanks go to Ian Jacobs for ample help with editing. Tim
Berners-Lee and James Clark provided important details in the section on URIs.
The W3C I18N WG and IG, as well as others, provided many comments and
suggestions.
References
Normative References
- IANA
- Internet Assigned Numbers Authority, Official
Names for Character Sets. (See ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.)
- ISO/IEC 10646
- ISO/IEC 10646, Information
technology -- Universal Multiple-Octet Coded Character Set
(UCS). Published as multiple parts; amendments are published
between major editions. (See http://www.iso.ch/ for the latest
version.)
- ISO/IEC 10646-1:2000
- ISO/IEC 10646-1:2000, Information technology
-- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1:
Architecture and Basic Multilingual Plane. (See http://www.iso.ch/cate/d29819.html.)
- MIME
- Multipurpose
Internet Mail Extensions (MIME). Part One: Format of Internet Message
Bodies, N. Freed, N. Borenstein, RFC 2045, November 1996,
<http://www.ietf.org/rfc/rfc2045.txt>.
Part Two: Media Types, N. Freed, N. Borenstein, RFC 2046,
November 1996. Part Three: Message Header Extensions for Non-ASCII
Text, K. Moore, RFC 2047, November 1996. Part Four:
Registration Procedures, N. Freed, J. Klensin, J. Postel, RFC
2048, November 1996. Part Five: Conformance Criteria and
Examples, N. Freed, N. Borenstein, RFC 2049, November 1996.
- RFC 2119
- S. Bradner, Key
words for use in RFCs to Indicate Requirement Levels, IETF
RFC 2119. (See http://www.ietf.org/rfc/rfc2119.txt.)
- RFC 2396
- T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource
Identifiers (URI): Generic Syntax, IETF RFC 2396, August
1998. (See http://www.ietf.org/rfc/rfc2396.txt.)
- RFC 2732
- R. Hinden, B. Carpenter, L. Masinter, Format for Literal IPv6
Addresses in URL's, IETF RFC 2732, 1999. (See http://www.ietf.org/rfc/rfc2732.txt.)
- UTR #15
- Mark Davis, Martin Dürst, Unicode
Normalization Forms, Unicode Technical Report #15. (See http://www.unicode.org/unicode/reports/tr15/
for the latest revision). Revision
18 (November 1999) is at http://www.unicode.org/unicode/reports/tr15/tr15-18.html.
- Unicode
- The Unicode Consortium, The Unicode Standard. (See http://www.unicode.org/unicode/standard/versions/
for the latest version and additional information on versions of the
standard and of the Unicode Character Database).
- Unicode 3.0
- The Unicode Consortium, The Unicode Standard -- Version
3.0, ISBN 0-201-61633-5. (See http://www.unicode.org/unicode/standard/versions/Unicode3.0.html.)
Other References
- CharReq
- Martin J. Dürst, Requirements for String
Identity and Character Indexing Definitions for the WWW, W3C
Working Draft. (See http://www.w3.org/TR/WD-charreq.)
- Connolly
- D. Connolly, Character
Set Considered Harmful, W3C Note. (See http://www.w3.org/MarkUp/html-spec/charset-harmful.)
- CSS2
- Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, Eds., Cascading Style Sheets, level
2 (CSS2 Specification), W3C Recommendation. (See http://www.w3.org/TR/REC-CSS2.)
- DOM Level 1
- Vidur Apparao et al., Document Object Model
(DOM) Level 1 Specification, W3C Recommendation. (See http://www.w3.org/TR/REC-DOM-Level-1/.)
- HTML 4.0
- Dave Raggett, Arnaud Le Hors, Ian Jacobs, Eds., HTML 4.0
Specification, W3C Recommendation 18-Dec-1997 (See http://www.w3.org/TR/REC-html40-971218/.)
- HTML 4.01
- Dave Raggett, Arnaud Le Hors, Ian Jacobs, Eds., HTML 4.01
Specification, W3C Recommendation 24-Dec-1999. (See http://www.w3.org/TR/html401/.)
- I-D URI-I18N
- Larry Masinter, Martin Dürst, Internationalized
Resource Identifiers (IRI), Internet-Draft, January 2001,
work in progress. (See http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-07.txt.)
- Info URI-I18N
- Internationalization:
URIs and other identifiers. (See http://www.w3.org/International/O-URL-and-ident.)
- MathML2
- David Carlisle, Patrick Ion, Robert Miner, Nico Poppelier, Eds., Mathematical Markup Language
(MathML) Version 2.0, W3C Proposed Recommendation 8 January
2001. (See http://www.w3.org/TR/MathML2.)
- Nicol
- Gavin Nicol, The
Multilingual World Wide Web, Chapter 2: The WWW As A
Multilingual Application. (See http://www.oasis-open.org/cover/nicol-multwww.html.)
- RFC 2070
- F. Yergeau, G. Nicol, G. Adams, M. Dürst, Internationalization of
the Hypertext Markup Language, IETF RFC 2070, January 1997.
(See http://www.ietf.org/rfc/rfc2070.txt.)
- RFC 2277
- H. Alvestrand, IETF Policy on
Character Sets and Languages, IETF RFC 2277, BCP 18, January
1998. (See http://www.ietf.org/rfc/rfc2277.txt.)
- RFC 2279
- F. Yergeau, UTF-8,
a transformation format of ISO 10646, IETF RFC 2279, January
1998. (See http://www.ietf.org/rfc/rfc2279.txt.)
- RFC 2781
- P. Hoffman, F. Yergeau, UTF-16, an encoding of
ISO 10646, IETF RFC 2781, February 2000. (See http://www.ietf.org/rfc/rfc2781.txt.)
- SPREAD
- SPREAD
- Standardization Project for East Asian Documents Universal Public
Entity Set. (See http://www.ascc.net/xml/resource/entities/index.html)
- SVG
- Jon Ferraiolo, Ed., Scalable
Vector Graphics (SVG) 1.0 Specification, W3C Candidate
Recommendation 2 November 2000. (See http://www.w3.org/TR/SVG/.)
- UTR #17
- Ken Whistler, Mark Davis, Character
Encoding Model, Unicode Technical Report #17. (See http://www.unicode.org/unicode/reports/tr17/.)
- UXML
- Martin Dürst and Asmus Freytag, Unicode in XML and other
Markup Languages, Unicode Technical Report #20 and W3C Note.
(See http://www.w3.org/TR/unicode-xml.)
- XLink
- Steve DeRose, Eve Maler, David Orchard, Eds, XML Linking
Language (XLink) Version 1.0, W3C Proposed Recommendation 20
December 2000. (See http://www.w3.org/TR/2000/PR-xlink-20001220/.)
- XML 1.0
- Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler Eds., Extensible Markup Language
(XML) 1.0, W3C Recommendation. (See http://www.w3.org/TR/REC-xml.)
- XML Japanese
profile
- MURATA Makoto Ed., XML Japanese
Profile, W3C Note. (See http://www.w3.org/TR/japanese-xml/.)
- XPath
- James Clark, Steve DeRose, Eds, XML Path Language (XPath)
Version 1.0, W3C Recommendation 16 November 1999. (See http://www.w3.org/TR/xpath.)
- XPointer
- Steve DeRose, Eve Maler, Ron Daniel Jr., Eds, XML Pointer
Language (XPointer) Version 1.0, W3C Last Call Working Draft
8 January 2001. (See http://www.w3.org/TR/2001/WD-xptr-20010108/.)
Change Log (Non-Normative)
Major restructuring and rewriting.
<space> 
