This
specification
defines
the
Second
Edition
of
XHTML
1.0,
a
reformulation
of
HTML 4
as
an
XML
1.0
application,
and
three
DTDs
corresponding
to
the
ones
defined
by
HTML 4.
The
semantics
of
the
elements
and
their
attributes
are
defined
in
the
W3C
Recommendation
for
HTML 4.
These
semantics
provide
the
foundation
for
future
extensibility
of
XHTML.
Compatibility
with
existing
HTML
user
agents
is
possible
by
following
a
small
set
of
guidelines.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
The
latest
status
of
this
document
series
is
maintained
at
the
W3C.
This
document
is
the
second
edition
of
the
XHTML
1.0
specification
incorporating
the
errata
changes
as
of
4
October
2001.
It
is
released
as
a
W3C
Working
Draft
to
gather
public
feedback
before
its
final
release
as
a
W3C
Recommendation.
This
document
should
not
be
used
as
reference
material
or
cited
as
a
normative
reference
from
another
document.
The
review
period
for
this
Working
Draft
is
4
weeks
ending
1
November
2001.
This
second
edition
is
not
a
new
version
of
XHTML
1.0
(first
published
26
January
2000).
The
changes
in
this
document
reflect
corrections
applied
as
a
result
of
comments
submitted
by
the
community
and
as
a
result
of
ongoing
work
within
the
HTML
Working
Group.
There
are
no
substantive
changes
in
this
document
-
only
the
integration
of
various
errata.
Please
report
errors
in
this
document
to
www-html-editor@w3.org
(
archive
).
This
document
has
been
produced
as
part
of
the
W3C
HTML
Activity
.
The
goals
of
the
HTML
Working
Group
(
members
only
)
are
discussed
in
the
HTML
Working
Group
charter
.
A
list
of
current
W3C
Recommendations
and
other
technical
documents
can
be
found
at
http://www.w3.org/TR
.
Public
discussion
on
HTML
features
takes
place
on
the
mailing
list
www-html@w3.org
(
archive
).
XHTML
is
a
family
of
current
and
future
document
types
and
modules
that
reproduce,
subset,
and
extend
HTML 4
[HTML]
.
XHTML
family
document
types
are
XML
based,
and
ultimately
are
designed
to
work
in
conjunction
with
XML-based
user
agents.
The
details
of
this
family
and
its
evolution
are
discussed
in
more
detail
in
the
section
on
Future
Directions
.
XHTML
1.0
(this
specification)
is
the
first
document
type
in
the
XHTML
family.
It
is
a
reformulation
of
the
three
HTML 4
document
types
as
applications
of
XML
1.0
[XML]
.
It
is
intended
to
be
used
as
a
language
for
content
that
is
both
XML-conforming
and,
if
some
simple
guidelines
are
followed,
operates
in
HTML 4
conforming
user
agents.
Developers
who
migrate
their
content
to
XHTML
1.0
will
realize
the
following
benefits:
-
XHTML
documents
are
XML
conforming.
As
such,
they
are
readily
viewed,
edited,
and
validated
with
standard
XML
tools.
-
XHTML
documents
can
be
written
to
to
operate
as
well
or
better
than
they
did
before
in
existing
HTML 4-conforming
user
agents
as
well
as
in
new,
XHTML
1.0
conforming
user
agents.
-
XHTML
documents
can
utilize
applications
(e.g.
scripts
and
applets)
that
rely
upon
either
the
HTML
Document
Object
Model
or
the
XML
Document
Object
Model
[DOM]
.
-
As
the
XHTML
family
evolves,
documents
conforming
to
XHTML
1.0
will
be
more
likely
to
interoperate
within
and
among
various
XHTML
environments.
The
XHTML
family
is
the
next
step
in
the
evolution
of
the
Internet.
By
migrating
to
XHTML
today,
content
developers
can
enter
the
XML
world
with
all
of
its
attendant
benefits,
while
still
remaining
confident
in
their
content's
backward
and
future
compatibility.
HTML
4
[HTML]
is
an
SGML
(Standard
Generalized
Markup
Language)
application
conforming
to
International
Standard
ISO
8879,
and
is
widely
regarded
as
the
standard
publishing
language
of
the
World
Wide
Web.
SGML
is
a
language
for
describing
markup
languages,
particularly
those
used
in
electronic
document
exchange,
document
management,
and
document
publishing.
HTML
is
an
example
of
a
language
defined
in
SGML.
SGML
has
been
around
since
the
middle
1980's
and
has
remained
quite
stable.
Much
of
this
stability
stems
from
the
fact
that
the
language
is
both
feature-rich
and
flexible.
This
flexibility,
however,
comes
at
a
price,
and
that
price
is
a
level
of
complexity
that
has
inhibited
its
adoption
in
a
diversity
of
environments,
including
the
World
Wide
Web.
HTML,
as
originally
conceived,
was
to
be
a
language
for
the
exchange
of
scientific
and
other
technical
documents,
suitable
for
use
by
non-document
specialists.
HTML
addressed
the
problem
of
SGML
complexity
by
specifying
a
small
set
of
structural
and
semantic
tags
suitable
for
authoring
relatively
simple
documents.
In
addition
to
simplifying
the
document
structure,
HTML
added
support
for
hypertext.
Multimedia
capabilities
were
added
later.
In
a
remarkably
short
space
of
time,
HTML
became
wildly
popular
and
rapidly
outgrew
its
original
purpose.
Since
HTML's
inception,
there
has
been
rapid
invention
of
new
elements
for
use
within
HTML
(as
a
standard)
and
for
adapting
HTML
to
vertical,
highly
specialized,
markets.
This
plethora
of
new
elements
has
led
to
compatibility
problems
for
documents
across
different
platforms.
As
the
heterogeneity
of
both
software
and
platforms
rapidly
proliferate,
it
is
clear
that
the
suitability
of
'classic'
HTML 4
for
use
on
these
platforms
is
somewhat
limited.
XML™
is
the
shorthand
for
Extensible
Markup
Language,
and
is
an
acronym
of
Extensible
Markup
Language
[XML]
.
XML
was
conceived
as
a
means
of
regaining
the
power
and
flexibility
of
SGML
without
most
of
its
complexity.
Although
a
restricted
form
of
SGML,
XML
nonetheless
preserves
most
of
SGML's
power
and
richness,
and
yet
still
retains
all
of
SGML's
commonly
used
features.
While
retaining
these
beneficial
features,
XML
removes
many
of
the
more
complex
features
of
SGML
that
make
the
authoring
and
design
of
suitable
software
both
difficult
and
costly.
The
benefits
of
migrating
to
XHTML
1.0
are
described
above.
Some
of
the
benefits
of
migrating
to
XHTML
in
general
are:
-
Document
developers
and
user
agent
designers
are
constantly
discovering
new
ways
to
express
their
ideas
through
new
markup.
In
XML,
it
is
relatively
easy
to
introduce
new
elements
or
additional
element
attributes.
The
XHTML
family
is
designed
to
accommodate
these
extensions
through
XHTML
modules
and
techniques
for
developing
new
XHTML-conforming
modules
(described
in
the
forthcoming
XHTML
Modularization
specification).
These
modules
will
permit
the
combination
of
existing
and
new
feature
sets
when
developing
content
and
when
designing
new
user
agents.
-
Alternate
ways
of
accessing
the
Internet
are
constantly
being
introduced.
Some
estimates
indicate
that
by
the
year
2002,
75%
of
Internet
document
viewing
will
be
carried
out
on
these
alternate
platforms.
The
XHTML
family
is
designed
with
general
user
agent
interoperability
in
mind.
Through
a
new
user
agent
and
document
profiling
mechanism,
servers,
proxies,
and
user
agents
will
be
able
to
perform
best
effort
content
transformation.
Ultimately,
it
will
be
possible
to
develop
XHTML-conforming
content
that
is
usable
by
any
XHTML-conforming
user
agent.
The
following
terms
are
used
in
this
specification.
These
terms
extend
the
definitions
in
[RFC2119]
in
ways
based
upon
similar
definitions
in
ISO/
IEC
9945-1:1990
[POSIX.1]
:
-
May
-
With
respect
to
implementations,
the
word
"may"
is
to
be
interpreted
as
an
optional
feature
that
is
not
required
in
this
specification
but
can
be
provided.
With
respect
to
Document
Conformance
,
the
word
"may"
means
that
the
optional
feature
must
not
be
used.
The
term
"optional"
has
the
same
definition
as
"may".
-
Must
-
In
this
specification,
the
word
"must"
is
to
be
interpreted
as
a
mandatory
requirement
on
the
implementation
or
on
Strictly
Conforming
XHTML
Documents,
depending
upon
the
context.
The
term
"shall"
has
the
same
definition
as
"must".
-
Reserved
-
A
value
or
behavior
is
unspecified,
but
it
is
not
allowed
to
be
used
by
Conforming
Documents
nor
to
be
supported
by
Conforming
User
Agents.
-
Should
-
With
respect
to
implementations,
the
word
"should"
is
to
be
interpreted
as
an
implementation
recommendation,
but
not
a
requirement.
With
respect
to
documents,
the
word
"should"
is
to
be
interpreted
as
recommended
programming
practice
for
documents
and
a
requirement
for
Strictly
Conforming
XHTML
Documents.
-
Supported
-
Certain
facilities
in
this
specification
are
optional.
If
a
facility
is
supported,
it
behaves
as
specified
by
this
specification.
-
Unspecified
-
When
a
value
or
behavior
is
unspecified,
the
specification
defines
no
portability
requirements
for
a
facility
on
an
implementation
even
when
faced
with
a
document
that
uses
the
facility.
A
document
that
requires
specific
behavior
in
such
an
instance,
rather
than
tolerating
any
behavior
when
using
that
facility,
is
not
a
Strictly
Conforming
XHTML
Document.
-
Attribute
-
An
attribute
is
a
parameter
to
an
element
declared
in
the
DTD.
An
attribute's
type
and
value
range,
including
a
possible
default
value,
are
defined
in
the
DTD.
-
DTD
-
A
DTD,
or
document
type
definition,
is
a
collection
of
XML
declarations
that,
as
a
collection,
defines
the
legal
structure,
elements
,
and
attributes
that
are
available
for
use
in
a
document
that
complies
to
the
DTD.
-
Document
-
A
document
is
a
stream
of
data
that,
after
being
combined
with
any
other
streams
it
references,
is
structured
such
that
it
holds
information
contained
within
elements
that
are
organized
as
defined
in
the
associated
DTD
.
See
Document
Conformance
for
more
information.
-
Element
-
An
element
is
a
document
structuring
unit
declared
in
the
DTD
.
The
element's
content
model
is
defined
in
the
DTD
,
and
additional
semantics
may
be
defined
in
the
prose
description
of
the
element.
-
Facilities
-
Functionality
includes
elements
,
attributes
,
and
the
semantics
associated
with
those
elements
and
attributes
.
An
implementation
supporting
that
functionality
is
said
to
provide
the
necessary
facilities.
-
Implementation
-
An
implementation
is
a
system
that
provides
collection
of
facilities
and
services
that
supports
this
specification.
See
User
Agent
Conformance
for
more
information.
-
Parsing
-
Parsing
is
the
act
whereby
a
document
is
scanned,
and
the
information
contained
within
the
document
is
filtered
into
the
context
of
the
elements
in
which
the
information
is
structured.
-
Rendering
-
Rendering
is
the
act
whereby
the
information
in
a
document
is
presented.
This
presentation
is
done
in
the
form
most
appropriate
to
the
environment
(e.g.
aurally,
visually,
in
print).
-
User
Agent
-
A
user
agent
is
an
implementation
that
retrieves
and
processes
XHTML
documents.
See
User
Agent
Conformance
for
more
information.
-
Validation
-
Validation
is
a
process
whereby
documents
are
verified
against
the
associated
DTD
,
ensuring
that
the
structure,
use
of
elements
,
and
use
of
attributes
are
consistent
with
the
definitions
in
the
DTD
.
-
Well-formed
-
A
document
is
well-formed
when
it
is
structured
according
to
the
rules
defined
in
Section
2.1
of
the
XML
1.0
Recommendation
[XML]
.
Basically,
this
definition
states
that
elements,
delimited
by
their
start
and
end
tags,
are
nested
properly
within
one
another.
This
version
of
XHTML
provides
a
definition
of
strictly
conforming
XHTML
documents,
which
are
restricted
to
tags
and
attributes
from
the
XML
and
XHTML
namespaces.
See
Section
3.1.2
for
information
on
using
XHTML
with
other
namespaces,
for
instance,
to
include
metadata
expressed
in
RDF
within
XHTML
documents.
A
Strictly
Conforming
XHTML
Document
is
a
document
that
requires
only
the
facilities
described
as
mandatory
in
this
specification.
Such
a
document
must
meet
all
of
the
following
criteria:
-
It
must
conform
to
the
constraints
expressed
in
one
of
the
three
DTDs
found
in
Appendix A
.
-
The
root
element
of
the
document
must
be
<html>
.
-
The
root
element
of
the
document
must
designate
the
XHTML
namespace
using
the
xmlns
attribute
[XMLNAMES]
.
The
namespace
for
XHTML
is
defined
to
be
http://www.w3.org/1999/xhtml
.
-
There
must
be
a
DOCTYPE
declaration
in
the
document
prior
to
the
root
element.
The
public
identifier
included
in
the
DOCTYPE
declaration
must
reference
one
of
the
three
DTDs
found
in
Appendix A
using
the
respective
Formal
Public
Identifier.
The
system
identifier
may
be
changed
to
reflect
local
system
conventions.
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
The
DTD
subset
must
not
be
used
to
override
any
parameter
entities
in
the
DTD.
Here
is
an
example
of
a
minimal
XHTML
document:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Virtual Library</title>
</head>
<body>
<p>Moved to <a href="http://vlib.org/">vlib.org</a>.</p>
</body>
</html>
Note
that
in
this
example,
the
XML
declaration
is
included.
An
XML
declaration
like
the
one
above
is
not
required
in
all
XML
documents.
XHTML
document
authors
are
strongly
encouraged
to
use
XML
declarations
in
all
their
documents.
Such
a
declaration
is
required
when
the
character
encoding
of
the
document
is
other
than
the
default
UTF-8
or
UTF-16
and
no
encoding
was
determined
by
a
higher-level
protocol.
The
XHTML
namespace
may
be
used
with
other
XML
namespaces
as
per
[XMLNAMES]
,
although
such
documents
are
not
strictly
conforming
XHTML
1.0
documents
as
defined
above.
Future
work
by
W3C
will
address
ways
to
specify
conformance
for
documents
involving
multiple
namespaces.
The
following
example
shows
the
way
in
which
XHTML
1.0
could
be
used
in
conjunction
with
the
MathML
Recommendation:
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>A Math Example</title>
</head>
<body>
<p>The following is MathML markup:</p>
<math xmlns="http://www.w3.org/1998/Math/MathML">
<apply> <log/>
<logbase>
<cn> 3 </cn>
</logbase>
<ci> x </ci>
</apply>
</math>
</body>
</html>
The
following
example
shows
the
way
in
which
XHTML
1.0
markup
could
be
incorporated
into
another
XML
namespace:
<?xml version="1.0" encoding="UTF-8"?>
<!-- initially, the default namespace is "books" -->
<book xmlns='urn:loc.gov:books'
xmlns:isbn='urn:ISBN:0-395-36341-6' xml:lang="en" lang="en">
<title>Cheaper by the Dozen</title>
<isbn:number>1568491379</isbn:number>
<notes>
<!-- make HTML the default namespace for a hypertext commentary -->
<p xmlns='http://www.w3.org/1999/xhtml'>
This is also available <a href="http://www.w3.org/">online</a>.
</p>
</notes>
</book>
A
conforming
user
agent
must
meet
all
of
the
following
criteria:
-
In
order
to
be
consistent
with
the
XML
1.0
Recommendation
[XML]
,
the
user
agent
must
parse
and
evaluate
an
XHTML
document
for
well-formedness.
If
the
user
agent
claims
to
be
a
validating
user
agent,
it
must
also
validate
documents
against
their
referenced
DTDs
according
to
[XML]
.
-
When
the
user
agent
claims
to
support
facilities
defined
within
this
specification
or
required
by
this
specification
through
normative
reference,
it
must
do
so
in
ways
consistent
with
the
facilities'
definition.
-
When
a
user
agent
processes
an
XHTML
document
as
generic
XML,
it
shall
only
recognize
attributes
of
type
ID
(e.g.
the
id
attribute
on
most
XHTML
elements)
as
fragment
identifiers.
-
If
a
user
agent
encounters
an
element
it
does
not
recognize,
it
must
process
the
element's
content.
-
If
a
user
agent
encounters
an
attribute
it
does
not
recognize,
it
must
ignore
the
entire
attribute
specification
(i.e.,
the
attribute
and
its
value).
-
If
a
user
agent
encounters
an
attribute
value
it
does
not
recognize,
it
must
use
the
default
attribute
value.
-
If
it
encounters
an
entity
reference
(other
than
one
of
the
predefined
entities)
for
which
the
User
Agent
has
processed
no
declaration
(which
could
happen
if
the
declaration
is
in
the
external
subset
which
the
User
Agent
hasn't
read),
the
entity
reference
should
be
processed
as
the
characters
(starting
with
the
ampersand
and
ending
with
the
semi-colon)
that
make
up
the
entity
reference.
-
When
processing
content,
User
Agents
that
encounter
characters
or
character
entity
references
that
are
recognized
but
not
renderable
should
display
the
document
in
such
a
way
that
it
is
obvious
to
the
user
that
normal
rendering
has
not
taken
place.
-
White
space
is
handled
according
to
the
following
rules.
The
following
characters
are
defined
in
[XML]
as
white
space
characters:
-
SPACE
( )
-
HORIZONTAL
TABULATION
(	)
-
CARRIAGE
RETURN
(
)
-
LINE
FEED
(
)
The
XML
processor
normalizes
different
systems'
line
end
codes
into
one
single
LINE
FEED
character,
that
is
passed
up
to
the
application.
The
user
agent
must
process
white
space
characters
in
the
data
received
from
the
XML
processor
as
follows:
-
After
XML
end
of
line
normalization,
white
space
characters
must
not
be
removed
from
the
XHTML
Infoset
as
they
may
be
processed
subsequently
by
style
language
processors.
Terms
like
'removed',
'preserved',
'converted'
and
'reduced'
used
in
the
next
clauses
only
apply
to
rendering
consideration
by
the
user
agent
in
the
absence
of
additional
processing
by
a
style
language
processor.
-
All
white
space
surrounding
block
elements
should
be
removed.
-
Comments
are
removed
entirely
and
do
not
affect
white
space
handling.
One
white
space
character
on
either
side
of
a
comment
is
treated
as
two
white
space
characters.
-
When
the
'
xml:space
'
attribute
is
set
to
'
preserve
',
white
space
characters
must
be
preserved
and
consequently
LINE
FEED
characters
within
a
block
must
not
be
converted.
-
When
the
'
xml:space
'
attribute
is
not
set
to
'
preserve
',
then:
-
Leading
and
trailing
white
space
inside
a
block
element
must
be
removed.
-
LINE
FEED
characters
must
be
converted
into
one
of
the
following
characters:
a
SPACE
character,
a
ZERO
WIDTH
SPACE
character
(​),
or
no
character
(i.e.
removed).
The
choice
of
the
resulting
character
is
user
agent
dependent
and
is
conditioned
by
the
script
property
of
the
characters
preceding
and
following
the
LINE
FEED
character.
-
A
sequence
of
white
space
characters
without
any
LINE
FEED
characters
must
be
reduced
to
a
single
SPACE
character.
-
A
sequence
of
white
space
characters
with
one
or
more
LINE
FEED
characters
must
be
reduced
in
the
same
way
as
a
single
LINE
FEED
character.
White
space
in
attribute
values
is
processed
according
to
[XML]
.
In
determining
how
to
convert
a
LINE
FEED
character
a
user
agent
must
meet
the
following
rules,
whereby
the
script
of
characters
on
either
side
of
the
LINE
FEED
determines
the
choice
of
the
replacement.
The
assignment
of
script
names
to
all
characters
is
done
in
accordance
to
the
Unicode
[UNICODE]
technical
report
TR#24
(Script
Names).
-
COMMON
script
characters
(such
as
punctuation)
are
treated
the
same
as
if
they
belong
to
the
same
script
as
the
character
on
the
other
side.
-
INHERITED
script
characters
(such
as
combining
characters)
are
treated
as
if
they
belong
to
the
same
script
as
the
previous
character
if
preceding
the
LINE
FEED
character
or
the
same
script
as
the
character
on
the
preceding
side
if
following
the
LINE
FEED
character.
-
If
the
characters
preceding
and
following
the
LINE
FEED
character
belong
to
HAN,
HIRAGANA
or
KATAKANA
script,
the
LINE
FEED
must
be
converted
into
no
character.
-
If
the
characters
preceding
and
following
the
LINE
FEED
character
belong
to
KHMER,
LAO,
MYANMAR
or
THAI
script,
the
LINE
FEED
must
be
converted
into
a
ZERO
WIDTH
SPACE
character
(​)
or
no
character.
(This
rule
may
be
extended
in
the
future
to
additional
scripts,
not
yet
encoded,
that
do
not
separate
their
words
by
space
characters)
-
If
none
of
the
conditions
in
(3)
through
(4)
are
true,
the
LINE
FEED
character
must
be
converted
into
a
SPACE
character.
This
covers
the
case
of
many
scripts
like
LATIN,
CYRILLIC,
GREEK,
etc.
This
also
covers
the
case
that
only
the
COMMON
script
has
been
detected
on
both
sides,
and
the
case
that
scripts
belong
to
different
categories.
Note
(informative):
Some
scripts,
such
as
HAN,
HIRAGANA,
KATAKANA,
KHMER,
LAO,
MYANMAR,
THAI
do
not
use
space
characters
for
word
boundary
delimitation,
but
may
still
use
these
space
characters
for
delimitation
of
sentences
or
fragments
of
sentence.
If
such
a
character
occurs
as
the
last
character
before
a
LINE
FEED
character,
or
a
character
following
a
LINE
FEED
character,
it
may
be
eliminated
by
the
white
space
processing
described
above.
Several
solutions
are
possible:
-
Make
sure
that
these
delimitation
space
characters
do
not
occur
next
to
a
LINE
FEED
character
and
that
authoring
tools
either
do
not
reflow
text
in
these
scripts,
or
only
reflow
such
text
while
preserving
the
white
space
in
a
way
appropriate
for
these
scripts.
-
Ensure
that
a
ZERO
WIDTH
SPACE
is
inserted
after
each
delimitation
space
and
that
authoring
tools
preserve
both
SPACE
and
ZERO
WIDTH
SPACE
together
at
the
end
of
a
line
during
reflow.
Note
that
in
order
to
produce
a
Canonical
XHTML
document,
the
rules
above
must
be
applied
and
the
rules
in
[XMLC14N]
must
also
be
applied
to
the
document.
This
section
is
informative.
Due
to
the
fact
that
XHTML
is
an
XML
application,
certain
practices
that
were
perfectly
legal
in
SGML-based
HTML 4
[HTML]
must
be
changed.
Well-formedness
is
a
new
concept
introduced
by
[XML]
.
Essentially
this
means
that
all
elements
must
either
have
closing
tags
or
be
written
in
a
special
form
(as
described
below),
and
that
all
the
elements
must
nest
properly.
Although
overlapping
is
illegal
in
SGML,
it
is
widely
tolerated
in
existing
browsers.
CORRECT:
nested
elements.
<p>here
is
an
emphasized
<em>paragraph</em>.</p>
INCORRECT:
overlapping
elements
<p>here
is
an
emphasized
<em>paragraph.</p></em>
XHTML
documents
must
use
lower
case
for
all
HTML
element
and
attribute
names.
This
difference
is
necessary
because
XML
is
case-sensitive
e.g.
<li>
and
<LI>
are
different
tags.
In
SGML-based
HTML
4
certain
elements
were
permitted
to
omit
the
end
tag;
with
the
elements
that
followed
implying
closure.
XML
does
not
allow
end
tags
to
be
omitted.
All
elements
other
than
those
declared
in
the
DTD
as
EMPTY
must
have
an
end
tag.
Elements
that
are
declared
in
the
DTD
as
EMPTY
can
have
an
end
tag
or
can
use
empty
element
shorthand
(see
Empty
Elements
).
CORRECT:
terminated
elements
<p>here
is
a
paragraph.</p><p>here
is
another
paragraph.</p>
INCORRECT:
unterminated
elements
<p>here
is
a
paragraph.<p>here
is
another
paragraph.
All
attribute
values
must
be
quoted,
even
those
which
appear
to
be
numeric.
CORRECT:
quoted
attribute
values
<table
rows="3">
INCORRECT:
unquoted
attribute
values
<table
rows=3>
XML
does
not
support
attribute
minimization.
Attribute-value
pairs
must
be
written
in
full.
Attribute
names
such
as
compact
and
checked
cannot
occur
in
elements
without
their
value
being
specified.
CORRECT:
unminimized
attributes
<dl
compact="compact">
INCORRECT:
minimized
attributes
<dl
compact>
Empty
elements
must
either
have
an
end
tag
or
the
start
tag
must
end
with
/>
.
For
instance,
<br/>
or
<hr></hr>
.
See
HTML
Compatibility
Guidelines
for
information
on
ways
to
ensure
this
is
backward
compatible
with
HTML
4
user
agents.
CORRECT:
terminated
empty
elements
<br/><hr/>
INCORRECT:
unterminated
empty
elements
<br><hr>
In
attribute
values,
user
agents
will
strip
leading
and
trailing
white
space
from
attribute
values
and
map
sequences
of
one
or
more
white
space
characters
(including
line
breaks)
to
a
single
inter-word
space
(an
ASCII
space
character
for
western
scripts).
See
Section
3.3.3
of
[XML]
.
In
XHTML,
the
script
and
style
elements
are
declared
as
having
#PCDATA
content.
As
a
result,
<
and
&
will
be
treated
as
the
start
of
markup,
and
entities
such
as
<
and
&
will
be
recognized
as
entity
references
by
the
XML
processor
to
<
and
&
respectively.
Wrapping
the
content
of
the
script
or
style
element
within
a
CDATA
marked
section
avoids
the
expansion
of
these
entities.
<script type="text/javascript">
<![CDATA[
... unescaped script content ...
]]>
</script>
CDATA
sections
are
recognized
by
the
XML
processor
and
appear
as
nodes
in
the
Document
Object
Model,
see
Section
1.3
of
the
DOM
Level
1
Recommendation
[DOM]
.
An
alternative
is
to
use
external
script
and
style
documents.
SGML
gives
the
writer
of
a
DTD
the
ability
to
exclude
specific
elements
from
being
contained
within
an
element.
Such
prohibitions
(called
"exclusions")
are
not
possible
in
XML.
For
example,
the
HTML
4
Strict
DTD
forbids
the
nesting
of
an
'
a
'
element
within
another
'
a
'
element
to
any
descendant
depth.
It
is
not
possible
to
spell
out
such
prohibitions
in
XML.
Even
though
these
prohibitions
cannot
be
defined
in
the
DTD,
certain
elements
should
not
be
nested.
A
summary
of
such
elements
and
the
elements
that
should
not
be
nested
in
them
is
found
in
the
normative
Appendix B
.
HTML
4
defined
the
name
attribute
for
the
elements
a
,
applet
,
form
,
frame
,
iframe
,
img
,
and
map
.
HTML
4
also
introduced
the
id
attribute.
Both
of
these
attributes
are
designed
to
be
used
as
fragment
identifiers.
In
XML,
fragment
identifiers
are
of
type
ID
,
and
there
can
only
be
a
single
attribute
of
type
ID
per
element.
Therefore,
in
XHTML
1.0
the
id
attribute
is
defined
to
be
of
type
ID
.
In
order
to
ensure
that
XHTML
1.0
documents
are
well-structured
XML
documents,
XHTML
1.0
documents
MUST
use
the
id
attribute
when
defining
fragment
identifiers
on
the
elements
listed
above.
See
the
HTML
Compatibility
Guidelines
for
information
on
ensuring
such
anchors
are
backwards
compatible
when
serving
XHTML
documents
as
media
type
text/html
.
Note
that
in
XHTML
1.0,
the
name
attribute
of
these
elements
is
formally
deprecated,
and
will
be
removed
in
a
subsequent
version
of
XHTML.
HTML
4
and
XHTML
both
have
some
attributes
that
have
pre-defined
and
limited
sets
of
values
(e.g.
the
type
attribute
of
the
input
element).
In
SGML
and
XML,
these
are
called
enumerated
attributes
.
Under
HTML
4,
the
interpretation
of
these
values
was
case-insensitive
,
so
a
value
of
TEXT
was
equivalent
to
a
value
of
text
.
Under
XML,
the
interpretation
of
these
values
is
case-sensitive
,
and
in
XHTML
1
all
of
these
values
are
defined
in
lower-case.
Although
there
is
no
requirement
for
XHTML
1.0
documents
to
be
compatible
with
existing
user
agents,
in
practice
this
is
easy
to
accomplish.
Guidelines
for
creating
compatible
documents
can
be
found
in
Appendix C
.
XHTML
Documents
which
follow
the
guidelines
set
forth
in
Appendix
C
,
"HTML
Compatibility
Guidelines"
may
be
labeled
with
the
Internet
Media
Type
"text/html",
as
they
are
compatible
with
most
HTML
browsers.
This
document
makes
no
recommendation
about
MIME
labeling
of
other
XHTML
documents.
XHTML
1.0
provides
the
basis
for
a
family
of
document
types
that
will
extend
and
subset
XHTML,
in
order
to
support
a
wide
range
of
new
devices
and
applications,
by
defining
modules
and
specifying
a
mechanism
for
combining
these
modules.
This
mechanism
will
enable
the
extension
and
sub-setting
of
XHTML
1.0
in
a
uniform
way
through
the
definition
of
new
modules.
As
the
use
of
XHTML
moves
from
the
traditional
desktop
user
agents
to
other
platforms,
it
is
clear
that
not
all
of
the
XHTML
elements
will
be
required
on
all
platforms.
For
example
a
hand
held
device
or
a
cell-phone
may
only
support
a
subset
of
XHTML
elements.
The
process
of
modularization
breaks
XHTML
up
into
a
series
of
smaller
element
sets.
These
elements
can
then
be
recombined
to
meet
the
needs
of
different
communities.
These
modules
are
defined
in
"
Modularization
of
XHTML
"
[
XHTMLMOD
].
Modularization
brings
with
it
several
advantages:
-
It
provides
a
formal
mechanism
for
sub-setting
XHTML.
-
It
provides
a
formal
mechanism
for
extending
XHTML.
-
It
simplifies
the
transformation
between
document
types.
-
It
promotes
the
reuse
of
modules
in
new
document
types.
This
appendix
is
normative.
These
DTDs
and
entity
sets
form
a
normative
part
of
this
specification.
The
complete
set
of
DTD
files
together
with
an
XML
declaration
and
SGML
Open
Catalog
is
included
in
the
zip
file
and
the
gzip'd
tar
file
for
this
specification.
Users
looking
for
local
copies
of
the
DTDs
to
work
with
should
download
and
use
those
archives
rather
than
using
the
specific
DTDs
referenced
below.
These
DTDs
approximate
the
HTML
4
DTDs.
It
is
likely
that
when
the
DTDs
are
modularized,
a
method
of
DTD
construction
will
be
employed
that
corresponds
more
closely
to
HTML
4.
The
XHTML
entity
sets
are
the
same
as
for
HTML
4,
but
have
been
modified
to
be
valid
XML
1.0
entity
declarations.
Note
the
entity
for
the
Euro
currency
sign
(
€
or
€
or
€
)
is
defined
as
part
of
the
special
characters.
This
appendix
is
normative.
The
following
elements
have
prohibitions
on
which
elements
they
can
contain
(see
Section
4.9
).
This
prohibition
applies
to
all
depths
of
nesting,
i.e.
it
contains
all
the
descendant
elements.
-
a
-
must
not
contain
other
a
elements.
-
pre
-
must
not
contain
the
img
,
object
,
big
,
small
,
sub
,
or
sup
elements.
-
button
-
must
not
contain
the
input
,
select
,
textarea
,
label
,
button
,
form
,
fieldset
,
iframe
or
isindex
elements.
-
label
-
must
not
contain
other
label
elements.
-
form
-
must
not
contain
other
form
elements.
This
appendix
is
informative.
This
appendix
summarizes
design
guidelines
for
authors
who
wish
their
XHTML
documents
to
render
on
existing
HTML
user
agents.
C.1
Processing
Instructions
and
the
XML
Declaration
Be
aware
that
processing
instructions
are
rendered
on
some
user
agents.
However,
also
note
that
when
the
XML
declaration
is
not
included
in
a
document,
the
document
can
only
use
the
default
character
encodings
UTF-8
or
UTF-16.
C.2
Empty
Elements
Include
a
space
before
the
trailing
/
and
>
of
empty
elements,
e.g.
<br />
,
<hr />
and
<img
src="karen.jpg"
alt="Karen" />
.
Also,
use
the
minimized
tag
syntax
for
empty
elements,
e.g.
<br
/>
,
as
the
alternative
syntax
<br></br>
allowed
by
XML
gives
uncertain
results
in
many
existing
user
agents.
C.3
Element
Minimization
and
Empty
Element
Content
Given
an
empty
instance
of
an
element
whose
content
model
is
not
EMPTY
(for
example,
an
empty
title
or
paragraph)
do
not
use
the
minimized
form
(e.g.
use
<p>
</p>
and
not
<p />
).
C.4
Embedded
Style
Sheets
and
Scripts
Use
external
style
sheets
if
your
style
sheet
uses
<
or
&
or
]]>
or
--
.
Use
external
scripts
if
your
script
uses
<
or
&
or
]]>
or
--
.
Note
that
XML
parsers
are
permitted
to
silently
remove
the
contents
of
comments.
Therefore,
the
historical
practice
of
"hiding"
scripts
and
style
sheets
within
"comments"
to
make
the
documents
backward
compatible
is
likely
to
not
work
as
expected
in
XML-based
implementations.
C.5
Line
Breaks
within
Attribute
Values
Avoid
line
breaks
and
multiple
white
space
characters
within
attribute
values.
These
are
handled
inconsistently
by
user
agents.
C.6
Isindex
Don't
include
more
than
one
isindex
element
in
the
document
head
.
The
isindex
element
is
deprecated
in
favor
of
the
input
element.
C.7
The
lang
and
xml:lang
Attributes
Use
both
the
lang
and
xml:lang
attributes
when
specifying
the
language
of
an
element.
The
value
of
the
xml:lang
attribute
takes
precedence.
C.8
Fragment
Identifiers
In
XML,
URI
-references
[
RFC2396
]
that
end
with
fragment
identifiers
of
the
form
"#foo"
do
not
refer
to
elements
with
an
attribute
name="foo"
;
rather,
they
refer
to
elements
with
an
attribute
defined
to
be
of
type
ID
,
e.g.,
the
id
attribute
in
HTML
4.
Many
existing
HTML
clients
don't
support
the
use
of
ID
-type
attributes
in
this
way,
so
identical
values
may
be
supplied
for
both
of
these
attributes
to
ensure
maximum
forward
and
backward
compatibility
(e.g.,
<a
id="foo"
name="foo">...</a>
).
Further,
since
the
set
of
legal
values
for
attributes
of
type
ID
is
much
smaller
than
for
those
of
type
CDATA
,
the
type
of
the
name
attribute
has
been
changed
to
NMTOKEN
.
This
attribute
is
constrained
such
that
it
can
only
have
the
same
values
as
type
ID
,
or
as
the
Name
production
in
XML
1.0
Section
2.3,
production
5.
Unfortunately,
this
constraint
cannot
be
expressed
in
the
XHTML
1.0
DTDs.
Because
of
this
change,
care
must
be
taken
when
converting
existing
HTML
documents.
The
values
of
these
attributes
must
be
unique
within
the
document,
valid,
and
any
references
to
these
fragment
identifiers
(both
internal
and
external)
must
be
updated
should
the
values
be
changed
during
conversion.
Note
that
the
collection
of
legal
values
in
XML
1.0
Section
2.3,
production
5
is
much
larger
than
that
permitted
to
be
used
in
the
ID
and
NAME
types
defined
in
HTML
4.
When
defining
fragment
identifiers
to
be
backward-compatible,
only
strings
matching
the
pattern
[A-Za-z][A-Za-z0-9:_.-]*
should
be
used.
See
[HTML]
Section
6.2
for
more
information.
Finally,
note
that
XHTML
1.0
has
deprecated
the
name
attribute
of
the
a
,
applet
,
form
,
frame
,
iframe
,
img
,
and
map
elements,
and
it
will
be
removed
from
XHTML
in
subsequent
versions.
C.9
Character
Encoding
To
specify
a
character
encoding
in
the
document,
use
both
the
encoding
attribute
specification
on
the
xml
declaration
(e.g.
<?xml
version="1.0"
encoding="EUC-JP"?>
)
and
a
meta
http-equiv
statement
(e.g.
<meta
http-equiv="Content-type"
content='text/html;
charset=EUC-JP' />
).
The
value
of
the
encoding
attribute
of
the
xml
declaration
takes
precedence.
C.10
Boolean
Attributes
Some
HTML
user
agents
are
unable
to
interpret
boolean
attributes
when
these
appear
in
their
full
(non-minimized)
form,
as
required
by
XML
1.0.
Note
this
problem
doesn't
affect
user
agents
compliant
with
HTML
4.
The
following
attributes
are
involved:
compact
,
nowrap
,
ismap
,
declare
,
noshade
,
checked
,
disabled
,
readonly
,
multiple
,
selected
,
noresize
,
defer
.
C.11
Document
Object
Model
and
XHTML
The
Document
Object
Model
level
1
Recommendation
[
DOM
]
defines
document
object
model
interfaces
for
XML
and
HTML
4.
The
HTML
4
document
object
model
specifies
that
HTML
element
and
attribute
names
are
returned
in
upper-case.
The
XML
document
object
model
specifies
that
element
and
attribute
names
are
returned
in
the
case
they
are
specified.
In
XHTML
1.0,
elements
and
attributes
are
specified
in
lower-case.
This
apparent
difference
can
be
addressed
in
two
ways:
-
Applications
that
access
XHTML
documents
served
as
Internet
media
type
text/html
via
the
DOM
can
use
the
HTML
DOM,
and
can
rely
upon
element
and
attribute
names
being
returned
in
upper-case
from
those
interfaces.
-
Applications
that
access
XHTML
documents
served
as
Internet
media
types
text/xml
or
application/xml
can
also
use
the
XML
DOM.
Elements
and
attributes
will
be
returned
in
lower-case.
Also,
some
XHTML
elements
may
or
may
not
appear
in
the
object
tree
because
they
are
optional
in
the
content
model
(e.g.
the
tbody
element
within
table
).
This
occurs
because
in
HTML
4
some
elements
were
permitted
to
be
minimized
such
that
their
start
and
end
tags
are
both
omitted
(an
SGML
feature).
This
is
not
possible
in
XML.
Rather
than
require
document
authors
to
insert
extraneous
elements,
XHTML
has
made
the
elements
optional.
Applications
need
to
adapt
to
this
accordingly.
C.12
Using
Ampersands
in
Attribute
Values
When
an
attribute
value
contains
an
ampersand,
it
must
be
expressed
as
a
character
entity
reference
(e.g.
"
&
").
For
example,
when
the
href
attribute
of
the
a
element
refers
to
a
CGI
script
that
takes
parameters,
it
must
be
expressed
as
http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user
rather
than
as
http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user
.
C.13
Cascading
Style
Sheets
(CSS)
and
XHTML
The
Cascading
Style
Sheets
level
2
Recommendation
[
CSS2
]
defines
style
properties
which
are
applied
to
the
parse
tree
of
the
HTML
or
XML
documents.
Differences
in
parsing
will
produce
different
visual
or
aural
results,
depending
on
the
selectors
used.
The
following
hints
will
reduce
this
effect
for
documents
which
are
served
without
modification
as
both
media
types:
-
CSS
style
sheets
for
XHTML
should
use
lower
case
element
and
attribute
names.
-
In
tables,
the
tbody
element
will
be
inferred
by
the
parser
of
an
HTML
user
agent,
but
not
by
the
parser
of
an
XML
user
agent.
Therefore
you
should
always
explicitly
add
a
tbody
element
if
it
is
referred
to
in
a
CSS
selector.
-
Within
the
XHTML
name
space,
user
agents
are
expected
to
recognize
the
"id"
attribute
as
an
attribute
of
type
ID.
Therefore,
style
sheets
should
be
able
to
continue
using
the
shorthand
"#"
selector
syntax
even
if
the
user
agent
does
not
read
the
DTD.
-
Within
the
XHTML
name
space,
user
agents
are
expected
to
recognize
the
"class"
attribute.
Therefore,
style
sheets
should
be
able
to
continue
using
the
shorthand
"."
selector
syntax.
-
CSS
defines
different
conformance
rules
for
HTML
and
XML
documents;
be
aware
that
the
HTML
rules
apply
to
XHTML
documents
delivered
as
HTML
and
the
XML
rules
apply
to
XHTML
documents
delivered
as
XML.
C.14
Referencing
Style
Elements
when
serving
as
XML
In
HTML
4
and
XHTML,
the
style
element
can
be
used
to
define
document-internal
style
rules.
In
XML,
an
XML
stylesheet
declaration
is
used
to
define
style
rules.
In
order
to
be
compatible
with
this
convention,
style
elements
should
have
their
fragment
identifier
set
using
the
id
attribute,
and
an
XML
stylesheet
declaration
should
reference
this
fragment.
For
example:
<?xml-stylesheet href="http://www.w3.org/StyleSheets/TR/W3C-REC.css" type="text/css"?>
<?xml-stylesheet href="#internalStyle" type="text/css"?>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>An internal stylesheet example</title>
<style id="internalStyle">
code {
color: green;
font-family: monospace;
font-weight: bold;
}
</style>
</head>
<body>
<p>
This is text that uses our
<code>internal stylesheet</code>.
</p>
</body>
</html>
C.15
White
Space
Characters
in
HTML
vs.
XML
Some
characters
that
are
legal
in
HTML
documents,
are
illegal
in
XML
document.
For
example,
in
HTML,
the
Formfeed
character
(U+000C)
is
treated
as
white
space,
in
XHTML,
due
to
XML's
definition
of
characters,
it
is
illegal.
C.16
The
Named
Character
Reference
'
The
named
character
reference
'
(the
apostrophe,
U+0027)
was
introduced
in
XML
1.0
but
does
not
appear
in
HTML.
Authors
should
therefore
use
'
instead
of
'
to
work
as
expected
in
HTML
4
user
agents.
This
appendix
is
informative.
This
specification
was
written
with
the
participation
of
the
members
of
the
W3C
HTML
Working
Group.
At
publication
of
the
second
edition,
the
membership
was:
-
Steven
Pemberton,
CWI
(HTML
Working
Group
Chair)
Murray
Altheim,
Sun
Microsystems
Daniel
Austin,
Mozquito
Technologies
Jonny
Axelsson,
Opera
Software
Tantek
Çelik,
Microsoft
Doug
Dominiak,
Openwave
Systems
Herman
Elenbaas,
Philips
Electronics
Beth
Epperson,
Netscape/
AOL
Masayasu
Ishikawa,
W3C
(HTML
Activity
Lead)
Shin'ichi
Matsui,
Panasonic
Shane
McCarron,
Applied
Testing
and
Technology
Rob
Relyea,
Microsoft
Ann
Navarro,
WebGeek,
Inc.
Peter
Stark,
Ericsson
Jeremy
Wadsworth,
Quark
Inc.
Malte
Wedel,
Mozquito
Technologies
Ted
Wugofski,
Openwave
Systems
At
publication
of
the
first
edition,
the
membership
was:
-
Steven
Pemberton,
CWI
(HTML
Working
Group
Chair)
Murray
Altheim,
Sun
Microsystems
Daniel
Austin,
AskJeeves
(CNET:
The
Computer
Network
through
July
1999)
Frank
Boumphrey,
HTML
Writers
Guild
John
Burger,
Mitre
Andrew
W.
Donoho,
IBM
Sam
Dooley,
IBM
Klaus
Hofrichter,
GMD
Philipp
Hoschka,
W3C
Masayasu
Ishikawa,
W3C
Warner
ten
Kate,
Philips
Electronics
Peter
King,
Phone.com
Paula
Klante,
JetForm
Shin'ichi
Matsui,
Panasonic
(W3C
visiting
engineer
through
September
1999)
Shane
McCarron,
Applied
Testing
and
Technology
(The
Open
Group
through
August
1999)
Ann
Navarro,
HTML
Writers
Guild
Zach
Nies,
Quark
Dave
Raggett,
W3C/HP
(HTML
Activity
Lead)
Patrick
Schmitz,
Microsoft
Sebastian
Schnitzenbaumer,
Stack
Overflow
Peter
Stark,
Phone.com
Chris
Wilson,
Microsoft
Ted
Wugofski,
Gateway
2000
Dan
Zigmond,
WebTV
Networks
This
appendix
is
informative.
-
[CSS2]
-
"
Cascading
Style
Sheets,
level
2
(CSS2)
Specification
",
B.
Bos,
H.
W.
Lie,
C.
Lilley,
I.
Jacobs,
12
May
1998.
Latest
version
available
at:
http://www.w3.org/TR/REC-CSS2
-
[DOM]
-
"
Document
Object
Model
(DOM)
Level
1
Specification
",
Lauren
Wood
et
al.
,
1
October
1998.
Latest
version
available
at:
http://www.w3.org/TR/REC-DOM-Level-1
-
[HTML]
-
"
HTML
4.01
Specification
",
D.
Raggett,
A.
Le Hors,
I.
Jacobs,
24
December
1999.
Latest
version
available
at:
http://www.w3.org/TR/html401
-
[POSIX.1]
-
"
ISO/IEC
9945-1:1990
Information
Technology
-
Portable
Operating
System
Interface
(POSIX)
-
Part
1:
System
Application
Program
Interface
(API)
[C
Language]
",
Institute
of
Electrical
and
Electronics
Engineers,
Inc,
1990.
-
[RFC2045]
-
"
Multipurpose
Internet
Mail
Extensions
(MIME)
Part
One:
Format
of
Internet
Message
Bodies
",
N.
Freed
and
N.
Borenstein,
November
1996.
Note
that
this
RFC
obsoletes
RFC1521,
RFC1522,
and
RFC1590.
-
[RFC2046]
-
"
RFC2046:
Multipurpose
Internet
Mail
Extensions
(MIME)
Part
Two:
Media
Types
",
N.
Freed
and
N.
Borenstein,
November
1996.
Available
at
http://www.ietf.org/rfc/rfc2046.txt
.
Note
that
this
RFC
obsoletes
RFC1521,
RFC1522,
and
RFC1590.
-
[RFC2119]
-
"
RFC2119:
Key
words
for
use
in
RFCs
to
Indicate
Requirement
Levels
",
S.
Bradner,
March
1997.
Available
at:
http://www.ietf.org/rfc/rfc2119.txt
-
[RFC2376]
-
"
RFC2376:
XML
Media
Types
",
E.
Whitehead,
M.
Murata,
July
1998.
This
document
is
obsoleted
by
[
RFC3023
].
Available
at:
http://www.ietf.org/rfc/rfc2376.txt
-
[RFC2396]
-
"
RFC2396:
Uniform
Resource
Identifiers
(URI):
Generic
Syntax
",
T.
Berners-Lee,
R.
Fielding,
L.
Masinter,
August
1998.
This
document
updates
RFC1738
and
RFC1808.
Available
at:
http://www.ietf.org/rfc/rfc2396.txt
-
[RFC3023]
-
"
RFC3023:
XML
Media
Types
",
M.
Murata,
S.
St.Laurent,
D.
Kohn,
January
2001.
This
document
obsoletes
[
RFC2376
].
Available
at:
http://www.ietf.org/rfc/rfc3023.txt
-
[RFC3066]
-
"
Tags
for
the
Identification
of
Languages
",
H.
Alvestrand,
January
2001.
Available
at:
http://www.ietf.org/rfc/rfc3066.txt
-
[ISO10646]
-
"
Information
Technology
--
Universal
Multiple-Octet
Coded
Character
Set
(UCS)
--
Part
1:
Architecture
and
Basic
Multilingual
Plane
",
ISO/IEC
10646-1:2000.
This
reference
refers
to
a
set
of
codepoints
that
may
evolve
as
new
characters
are
assigned
to
them.
Also,
this
reference
assumes
that
the
character
sets
defined
by
ISO
10646
and
[UNICODE]
remain
character-by-character
equivalent.
This
reference
also
includes
future
publications
of
other
parts
of
10646
(i.e.,
other
than
Part
1)
that
define
characters
in
planes
1-16.
-
[UNICODE]
-
"
The
Unicode
Standard,
Version
3.1.1
",
The
Unicode
Consortium.
This
version
is
defined
by:
The
Unicode
Standard,
Version
3.0
(Reading,
MA,
Addison-Wesley,
2000.
ISBN
0-201-61633-5),
as
amended
by
the
Unicode
Standard
Annex
#27:
Unicode
3.1
(http://www.unicode.org/reports/tr27/)
and
the
Unicode
3.1.1
Update
Notice
(http://www.unicode.org/versions/Unicode3.1.1.html).
For
more
information
about
Unicode,
see
http://www.unicode.org
.
-
[XHTMLMOD]
-
"
Modularization
of
XHTML
",
M.
Altheim
et
al.,
10
April
2001.
Latest
version
available
at:
http://www.w3.org/TR/xhtml-modularization
-
[XML]
-
"
Extensible
Markup
Language
(XML)
1.0
Specification
(Second
Edition)
",
T.
Bray,
J.
Paoli,
C.
M.
Sperberg-McQueen,
E.
Maler,
6
October
2000.
Latest
version
available
at:
http://www.w3.org/TR/REC-xml
-
[XMLNAMES]
-
"
Namespaces
in
XML
",
T.
Bray,
D.
Hollander,
A.
Layman,
14
January
1999.
XML
namespaces
provide
a
simple
method
for
qualifying
names
used
in
XML
documents
by
associating
them
with
namespaces
identified
by
URI.
Latest
version
available
at:
http://www.w3.org/TR/REC-xml-names
-
[XMLC14N]
-
"
Canonical
XML
Version
1.0
",
J.
Boyer,
15
March
2001.
This
document
describes
a
method
for
generating
a
physical
representation,
the
canonical
form,
of
an
XML
document.
Latest
version
available
at:
http://www.w3.org/TR/xml-c14n
