Abstract

This
document
is
the
second
edition
of
version
1.1
of
XHTML
Modularization,
an
abstract
modularization
of
XHTML
and
implementations
of
the
abstraction
using
XML
Document
Type
Definitions
(DTDs)
and
XML
Schemas.
This
modularization
provides
a
means
for
subsetting
and
extending
XHTML,
a
feature
needed
for
extending
XHTML's
reach
onto
emerging
platforms.
This
specification
is
intended
for
use
by
language
designers
as
they
construct
new
XHTML
Family
Markup
Languages.
This
specification
does
not
define
the
semantics
of
elements
and
attributes,
only
how
those
elements
and
attributes
are
assembled
into
modules,
and
from
those
modules
into
markup
languages.
This
update
includes
several
minor
updates
to
provide
clarifications
and
address
errors
found
in
version
1.1.

Status
of
This
Document

This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
http://www.w3.org/TR/.

This
document
has
been
reviewed
by
W3C
Members,
by
software
developers,
and
by
other
W3C
groups
and
interested
parties,
and
is
endorsed
by
the
Director
as
a
W3C
Recommendation.
It
is
a
stable
document
and
may
be
used
as
reference
material
or
cited
from
another
document.
W3C's
role
in
making
the
Recommendation
is
to
draw
attention
to
the
specification
and
to
promote
its
widespread
deployment.
This
enhances
the
functionality
and
interoperability
of
the
Web.

1.
Introduction

This
section
is
informative
.

1.1.
What
is
XHTML?

XHTML
is
the
reformulation
of
HTML
4
as
an
application
of
XML.
XHTML
1.0
[XHTML1]
specifies
three
XML
document
types
that
correspond
to
the
three
HTML
4
DTDs:
Strict,
Transitional,
and
Frameset.
XHTML
1.0
is
the
basis
for
a
family
of
document
types
that
subset
and
extend
HTML.

1.2.
What
is
XHTML
Modularization?

XHTML
Modularization
is
a
decomposition
of
XHTML
1.0,
and
by
reference
HTML
4,
into
a
collection
of
abstract
modules
that
provide
specific
types
of
functionality.
These
abstract
modules
are
implemented
in
this
specification
using
the
XML
Schema
and
XML
Document
Type
Definition
languages.
The
rules
for
defining
the
abstract
modules,
and
for
implementing
them
using
XML
Schemas
and
XML
DTDs,
are
also
defined
in
this
document.

These
modules
may
be
combined
with
each
other
and
with
other
modules
to
create
XHTML
subset
and
extension
document
types
that
qualify
as
members
of
the
XHTML-family
of
document
types.
Note
that
while
this
specification
only
contains
trivial
examples
of
combining
these
modules
into
markup
languages.
For
more
complete
examples,
see
[
XHTMLBASIC
]
or
[
XHTML11
].

1.3.
Why
Modularize
XHTML?

The
modularization
of
XHTML
refers
to
the
task
of
specifying
well-defined
sets
of
XHTML
elements
that
can
be
combined
and
extended
by
document
authors,
document
type
architects,
other
XML
standards
specifications,
and
application
and
product
designers
to
make
it
economically
feasible
for
content
developers
to
deliver
content
on
a
greater
number
and
diversity
of
platforms.

Over
the
last
couple
of
years,
many
specialized
markets
have
begun
looking
to
HTML
as
a
content
language.
There
is
a
great
movement
toward
using
HTML
across
increasingly
diverse
computing
platforms.
Currently
there
is
activity
to
move
HTML
onto
mobile
devices
(hand
held
computers,
portable
phones,
etc.),
television
devices
(digital
televisions,
TV-based
Web
browsers,
etc.),
and
appliances
(fixed
function
devices).
Each
of
these
devices
has
different
requirements
and
constraints.

Modularizing
XHTML
provides
a
means
for
product
designers
to
specify
which
elements
are
supported
by
a
device
using
standard
building
blocks
and
standard
methods
for
specifying
which
building
blocks
are
used.
These
modules
serve
as
"points
of
conformance"
for
the
content
community.
The
content
community
can
now
target
the
installed
base
that
supports
a
certain
collection
of
modules,
rather
than
worry
about
the
installed
base
that
supports
this
or
that
permutation
of
XHTML
elements.
The
use
of
standards
is
critical
for
modularized
XHTML
to
be
successful
on
a
large
scale.
It
is
not
economically
feasible
for
content
developers
to
tailor
content
to
each
and
every
permutation
of
XHTML
elements.
By
specifying
a
standard,
either
software
processes
can
autonomously
tailor
content
to
a
device,
or
the
device
can
automatically
load
the
software
required
to
process
a
module.

Modularization
also
allows
for
the
extension
of
XHTML's
layout
and
presentation
capabilities,
using
the
extensibility
of
XML,
without
breaking
the
XHTML
standard.
This
development
path
provides
a
stable,
useful,
and
implementable
framework
for
content
developers
and
publishers
to
manage
the
rapid
pace
of
technological
change
on
the
Web.

1.3.1.
Abstract
modules

An
XHTML
document
type
is
defined
as
a
set
of
abstract
modules.
A
abstract
module
defines
one
kind
of
data
that
is
semantically
different
from
all
others.
Abstract
modules
can
be
combined
into
document
types
without
a
deep
understanding
of
the
underlying
schemas
that
define
the
modules.

1.3.2.
Module
implementations

A
module
implementation
consists
of
a
set
of
element
types,
a
set
of
attribute-list
declarations,
and
a
set
of
content
model
declarations,
where
any
of
these
three
sets
may
be
empty.
An
attribute-list
declaration
in
a
module
may
modify
an
element
type
outside
the
element
types
defined
in
the
module,
and
a
content
model
declaration
may
modify
an
element
type
outside
the
element
type
set
of
the
module.

One
implementation
mechanism
is
XML
DTDs.
An
XML
DTD
is
a
means
of
describing
the
structure
of
a
class
of
XML
documents,
collectively
known
as
an
XML
document
type.
XML
DTDs
are
described
in
the
XML
1.0
Recommendation
[XML]
.
Another
implementation
mechanism
is
XML
Schema
[XMLSCHEMA]
.
For
purposes
of
discussion
in
this
document,
we
refer
to
the
various
implementations
of
XHTML
Modularization
as
"schema".

1.3.3.
Hybrid
document
types

A
hybrid
document
type
is
an
document
type
composed
from
a
collection
of
XML
document
types
or
Modules.
The
primary
purpose
of
the
modularization
framework
described
in
this
document
is
to
allow
a
document
type
author
to
combine
elements
from
multiple
abstract
modules
into
a
hybrid
document
type,
develop
documents
against
that
hybrid
document
type,
and
to
validate
that
document
against
the
associated
hybrid
schema.

One
of
the
most
valuable
benefits
of
XML
over
SGML
is
that
XML
reduces
the
barrier
to
entry
for
standardization
of
element
sets
that
allow
communities
to
exchange
data
in
an
interoperable
format.
However,
the
relatively
static
nature
of
HTML
as
the
content
language
for
the
Web
has
meant
that
any
one
of
these
communities
have
previously
held
out
little
hope
that
their
XML
document
types
would
be
able
to
see
widespread
adoption
as
part
of
Web
standards.
The
modularization
framework
allows
for
the
dynamic
incorporation
of
these
diverse
document
types
within
the
XHTML-family
of
document
types,
further
reducing
the
barriers
to
the
incorporation
of
these
domain-specific
vocabularies
in
XHTML
documents.

1.3.4.
Validation

The
use
of
well-formed,
but
not
valid,
documents
is
an
important
benefit
of
XML.
In
the
process
of
developing
a
document
type,
however,
the
additional
leverage
provided
by
a
validating
parser
for
error
checking
is
important.
The
same
statement
applies
to
XHTML
document
types
with
elements
from
multiple
abstract
modules.

An
XHTML-family
document
is
an
instance
of
one
particular
document
type
as
specified
by
the
document's
author,
either
in
the
document's
prologue
or
through
some
other
mechanism
(e.g.,
the
schemaLocation
attribute).
Validating
the
document
is
the
process
of
testing
whether
the
document
complies
with
the
rules
in
the
associated
schema.

One
document
can
consist
of
multiple
document
fragments.
Validating
only
fragments
of
a
document,
where
each
fragment
is
of
a
different
document
type
than
the
other
fragments
in
the
document,
is
beyond
the
scope
of
this
framework
-
since
it
would
require
technology
that
is
not
yet
defined.

However,
the
modularization
framework
allows
multiple
schema
to
be
integrated
and
form
a
new
document
type
(e.g.
SVG
integrated
into
XHTML).
The
new
schema
can
be
used
for
normal
XML
1.0
validation.

1.3.5.
Formatting
Model

Earlier
versions
of
HTML
attempted
to
define
parts
of
the
model
that
user
agents
are
required
to
use
when
formatting
a
document.
With
the
advent
of
HTML
4,
the
W3C
started
the
process
of
divorcing
presentation
from
structure.
XHTML
1.0
maintained
this
separation,
and
this
document
continues
moving
HTML
and
its
descendants
down
this
path.
Consequently,
this
document
makes
no
requirements
on
the
formatting
model
associated
with
the
presentation
of
documents
marked
up
with
XHTML
Family
document
types.

Instead,
this
document
recommends
that
content
authors
rely
upon
style
mechanisms
such
as
CSS
to
define
the
formatting
model
for
their
content.
When
user
agents
support
the
style
mechanisms,
documents
will
format
as
expected.
When
user
agents
do
not
support
the
style
mechanisms,
documents
will
format
as
appropriate
for
that
user
agent.
This
permits
XHTML
Family
user
agents
to
support
rich
formatting
models
on
devices
where
that
is
appropriate,
and
lean
formatting
models
on
devices
where
that
is
appropriate.

2.
Terms
and
Definitions

This
section
is
informative
.

While
some
terms
are
defined
in
place,
the
following
definitions
are
used
throughout
this
document.
Familiarity
with
the
W3C
XML
1.0
Recommendation
[XML]
is
highly
recommended.

abstract
module

a
unit
of
document
type
specification
corresponding
to
a
distinct
type
of
content,
corresponding
to
a
markup
construct
reflecting
this
distinct
type.

content
model

the
declared
markup
structure
allowed
within
instances
of
an
element
type.
XML
1.0
differentiates
two
types:
elements
containing
only
element
content
(no
character
data)
and
mixed
content
(elements
that
may
contain
character
data
optionally
interspersed
with
child
elements).
The
latter
are
characterized
by
a
content
specification
beginning
with
the
"#PCDATA"
string
(denoting
character
data).

document
model

the
effective
structure
and
constraints
of
a
given
document
type.
The
document
model
constitutes
the
abstract
representation
of
the
physical
or
semantic
structures
of
a
class
of
documents.

document
type

a
class
of
documents
sharing
a
common
abstract
structure.
The
ISO
8879
[SGML]
definition
is
as
follows:
"a
class
of
documents
having
similar
characteristics;
for
example,
journal,
article,
technical
manual,
or
memo.
(4.102)"

document
type
definition
(DTD)

a
formal,
machine-readable
expression
of
the
XML
structure
and
syntax
rules
to
which
a
document
instance
of
a
specific
document
type
must
conform;
the
schema
type
used
in
XML
1.0
to
validate
conformance
of
a
document
instance
to
its
declared
document
type.
The
same
markup
model
may
be
expressed
by
a
variety
of
DTDs.

driver

a
generally
short
file
used
to
declare
and
instantiate
the
modules
of
a
DTD.
A
good
rule
of
thumb
is
that
a
DTD
driver
contains
no
markup
declarations
that
comprise
any
part
of
the
document
model
itself.

element

an
instance
of
an
element
type.

element
type

the
definition
of
an
element,
that
is,
a
container
for
a
distinct
semantic
class
of
document
content.

entity

an
entity
is
a
logical
or
physical
storage
unit
containing
document
content.
Entities
may
be
composed
of
parse-able
XML
markup
or
character
data,
or
unparsed
(i.e.,
non-XML,
possibly
non-textual)
content.
Entity
content
may
be
either
defined
entirely
within
the
document
entity
("internal
entities")
or
external
to
the
document
entity
("external
entities").
In
parsed
entities,
the
replacement
text
may
include
references
to
other
entities.

elements
,
attributes
,
and
the
semantics
associated
with
those
elements
and
attributes
.

generic
identifier

the
name
identifying
the
element
type
of
an
element.
Also,
element
type
name.

hybrid
document

A
hybrid
document
is
a
document
that
uses
more
than
one
XML
namespace.
Hybrid
documents
may
be
defined
as
documents
that
contain
elements
or
attributes
from
hybrid
document
types.

instantiate

to
replace
an
entity
reference
with
an
instance
of
its
declared
content.

markup
declaration

a
syntactical
construct
within
a
DTD
declaring
an
entity
or
defining
a
markup
structure.
Within
XML
DTDs,
there
are
four
specific
types:
entity
declaration
defines
the
binding
between
a
mnemonic
symbol
and
its
replacement
content;
element
declaration
constrains
which
element
types
may
occur
as
descendants
within
an
element
(see
also
content
model);
attribute
definition
list
declaration
defines
the
set
of
attributes
for
a
given
element
type,
and
may
also
establish
type
constraints
and
default
values;
notation
declaration
defines
the
binding
between
a
notation
name
and
an
external
identifier
referencing
the
format
of
an
unparsed
entity.

markup
model

the
markup
vocabulary
(i.e.,
the
gamut
of
element
and
attribute
names,
notations,
etc.)
and
grammar
(i.e.,
the
prescribed
use
of
that
vocabulary)
as
defined
by
a
document
type
definition
(i.e.,
a
schema)
The
markup
model
is
the
concrete
representation
in
markup
syntax
of
the
document
model,
and
may
be
defined
with
varying
levels
of
strict
conformity.
The
same
document
model
may
be
expressed
by
a
variety
of
markup
models.

module

an
abstract
unit
within
a
document
model
expressed
as
a
DTD
fragment,
used
to
consolidate
markup
declarations
to
increase
the
flexibility,
modifiability,
reuse
and
understanding
of
specific
logical
or
semantic
structures.

modularization

an
implementation
of
a
modularization
model;
the
process
of
composing
or
de-composing
a
DTD
by
dividing
its
markup
declarations
into
units
or
groups
to
support
specific
goals.
Modules
may
or
may
not
exist
as
separate
file
entities
(i.e.,
the
physical
and
logical
structures
of
a
DTD
may
mirror
each
other,
but
there
is
no
such
requirement).

modularization
model

the
abstract
design
of
the
document
type
definition
(DTD)
in
support
of
the
modularization
goals,
such
as
reuse,
extensibility,
expressiveness,
ease
of
documentation,
code
size,
consistency
and
intuitiveness
of
use.
It
is
important
to
note
that
a
modularization
model
is
only
orthogonally
related
to
the
document
model
it
describes,
so
that
two
very
different
modularization
models
may
describe
the
same
document
type.

parameter
entity

an
entity
whose
scope
of
use
is
within
the
document
prolog
(i.e.,
the
external
subset/DTD
or
internal
subset).
Parameter
entities
are
disallowed
within
the
document
instance.

parent
document
type

A
parent
document
type
of
a
hybrid
document
is
the
document
type
of
the
root
element.

tag

descriptive
markup
delimiting
the
start
and
end
(including
its
generic
identifier
and
any
attributes)
of
an
element.

3.
Conformance
Definition

This
section
is
normative
.

In
order
to
ensure
that
XHTML-family
documents
are
maximally
portable
among
XHTML-family
user
agents,
this
specification
rigidly
defines
conformance
requirements
for
both
of
these
and
for
XHTML-family
document
types.
While
the
conformance
definitions
can
be
found
in
this
section,
they
necessarily
reference
normative
text
within
this
document,
within
the
base
XHTML
specification
[XHTML1]
,
and
within
other
related
specifications.
It
is
only
possible
to
fully
comprehend
the
conformance
requirements
of
XHTML
through
a
complete
reading
of
all
normative
references.

The
keywords
"MUST",
"MUST
NOT",
"REQUIRED",
"SHALL",
"SHALL
NOT",
"SHOULD",
"RECOMMENDED",
"MAY",
and
"OPTIONAL"
in
this
document
are
to
be
interpreted
as
described
in
[RFC2119]
.

3.1.
XHTML
Host
Language
Document
Type
Conformance

It
is
possible
to
modify
existing
document
types
and
define
wholly
new
document
types
using
both
modules
defined
in
this
specification
and
other
modules.
Such
a
document
type
is
"XHTML
Host
Language
Conforming"
when
it
meets
the
following
criteria:

The
document
type
MUST
be
defined
using
one
of
the
implementation
methods
defined
by
the
W3C.
Currently
this
is
limited
to
XML
DTDs
and
XML
Schema.

The
schema
which
defines
the
document
type
MUST
have
a
unique
identifier
as
defined
in
Naming
Rules
that
begins
with
the
character
sequence
"
XHTML
".

The
schema
which
defines
the
document
type
must
include,
at
a
minimum,
the
Structure,
Hypertext,
Text,
and
List
modules
defined
in
this
specification.

For
each
of
the
W3C-defined
modules
that
are
included,
all
of
the
elements,
attributes,
types
of
attributes
(including
any
required
enumerated
value
lists),
and
any
required
minimal
content
models
must
be
included
(and
optionally
extended)
in
the
document
type's
content
model.
When
content
models
are
extended,
all
of
the
elements
and
attributes
(along
with
their
types
or
any
required
enumerated
value
lists)
required
in
the
original
content
model
must
continue
to
be
required.

The
schema
that
defines
the
document
type
may
define
additional
elements
and
attributes.
However,
these
MUST
be
in
their
own
XML
namespace
[XMLNAMES]
.
If
additional
elements
are
defined
by
a
module,
the
attributes
defined
in
included
XHTML
modules
are
available
for
use
on
those
elements,
but
SHOULD
be
referenced
using
their
namespace-qualified
identifier
(e.g.,
xhtml:class).
The
semantics
of
the
attributes
remain
the
same
as
when
used
on
an
XHTML-namespace
element.

3.2.
XHTML
Integration
Set
Document
Type
Conformance

It
is
also
possible
to
define
document
types
that
are
based
upon
XHTML,
but
do
not
adhere
to
its
structure.
Such
a
document
type
is
"XHTML
Integration
Set
Conforming"
when
it
meets
the
following
criteria:

The
document
type
MUST
be
defined
using
one
of
the
implementation
methods
defined
by
the
W3C.
Currently
this
is
limited
to
XML
DTDs
and
XML
Schemas.

The
schema
that
defines
the
document
type
MUST
have
a
unique
identifier
as
defined
in
Naming
Rules
.
This
identifier
MUST
contain
the
character
sequence
"XHTML",
but
MUST
NOT
start
with
that
character
sequence.

The
schema
which
defines
the
document
type
MUST
include,
at
a
minimum,
the
Hypertext,
Text,
and
List
modules
defined
in
this
specification.

For
each
of
the
W3C-defined
modules
that
are
included,
all
of
the
elements,
attributes,
types
of
attributes
(including
any
required
enumerated
lists),
and
any
required
minimal
content
models
MUST
be
included
(and
optionally
extended)
in
the
document
type's
content
model.
When
content
models
are
extended,
all
of
the
elements
and
attributes
(along
with
their
types
or
any
required
enumerated
value
lists)
required
in
the
original
content
model
MUST
continue
to
be
required.

The
schema
that
defines
the
document
type
MAY
define
additional
elements
and
attributes.
However,
these
MUST
be
in
their
own
XML
namespace
[XMLNAMES]
.
If
additional
elements
are
defined
by
a
module,
the
attributes
defined
in
included
XHTML
modules
are
available
for
use
on
those
elements,
but
SHOULD
be
referenced
using
their
namespace-qualified
identifier
(e.g.,
xhtml:class).
The
semantics
of
the
attributes
remain
the
same
as
when
used
on
an
XHTML-namespace
element.

3.3.
XHTML
Family
Module
Conformance

This
specification
defines
a
method
for
defining
XHTML-conforming
modules.
A
module
conforms
to
this
specification
when
it
meets
all
of
the
following
criteria:

The
document
type
MUST
be
defined
using
one
of
the
implementation
methods
defined
by
the
W3C.
Currently
this
is
limited
to
XML
DTDs
and
XML
Schemas.

The
schema
that
defines
the
module
MUST
have
a
unique
identifier
as
defined
in
Naming
Rules
.

When
the
module
is
defined
using
an
XML
DTD,
the
module
MUST
isolate
its
parameter
entity
names
through
the
use
of
unique
prefixes
or
other,
similar
methods.

The
module
definition
MUST
have
a
prose
definition
that
describes
the
syntactic
and
semantic
requirements
of
the
elements,
attributes,
and/or
content
models
that
it
declares.
For
the
avoidance
of
doubt,
if
there
is
any
discrepancy
between
the
prose
definition
of
a
module
and
its
schema
implementation(s),
the
prose
definition
MUST
take
precedence.

The
module
definition
MUST
NOT
reuse
any
element
names
that
are
defined
in
other
W3C-defined
modules,
except
when
the
content
model
and
semantics
of
those
elements
are
either
identical
to
the
original
or
an
extension
of
the
original,
or
when
the
reused
element
names
are
within
their
own
XML
namespace
(see
below).

The
module
definition's
elements
and
attributes
MUST
be
part
of
an
XML
namespace
[XMLNAMES]
.
If
the
module
is
defined
by
an
organization
other
than
the
W3C,
this
namespace
MUST
NOT
be
the
same
as
the
namespace
in
which
other
W3C
modules
are
defined.

3.4.
XHTML
Family
Document
Conformance

A
conforming
XHTML
family
document
is
a
valid
instance
of
an
XHTML
Host
Language
Conforming
Document
Type.
For
the
avoidance
of
doubt,
the
behavior
of
User
Agents
in
the
presence
of
invalid
documents
is
undefined.

3.5.
XHTML
Family
User
Agent
Conformance

A
conforming
user
agent
must
meet
all
of
the
following
criteria
(as
defined
in
[XHTML1]
):

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
schemas.

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
MUST
recognize
only
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
continue
to
process
the
children
of
that
element.

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
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
rendered
as
the
characters
(starting
with
the
ampersand
and
ending
with
the
semi-colon)
that
make
up
the
entity
reference.

When
rendering
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.

Whitespace
is
defined
as
in
[XML]
.
On
input
all
whitespace
is
preserved
-
this
is
exactly
as
if
the
value
of
xml:space
,
as
defined
in
[XML]
,
is
set
to
"preserve".
If
the
value
of
that
attribute
is
set
to
"default",
that
is
the
same
as
if
it
were
set
to
"preserve".
On
rendering,
whitespace
is
processed
according
to
the
rules
of
[CSS2]
.

3.6.
Naming
Rules

XHTML
Host
Language
document
types
must
adhere
to
strict
naming
conventions
so
that
it
is
possible
for
software
and
users
to
readily
determine
the
relationship
of
document
types
to
XHTML.
The
names
for
document
types
implemented
as
XML
Document
Type
Definitions
are
defined
through
Formal
Public
Identifiers
(FPIs).
Within
FPIs,
fields
are
separated
by
double
slash
character
sequences
(
//
).
The
various
fields
must
be
composed
as
follows:

The
leading
field
must
be
"-"
to
indicate
a
privately
defined
resource.

The
second
field
must
contain
the
name
of
the
organization
responsible
for
maintaining
the
named
item.
There
is
no
formal
registry
for
these
organization
names.
Each
organization
should
define
a
name
that
is
unique.
The
name
used
by
the
W3C
is,
for
example,
W3C
.

The
third
field
contains
two
constructs:
the
public
text
class
followed
by
the
public
text
description.
The
first
token
in
the
third
field
is
the
public
text
class
which
should
adhere
to
ISO
8879
Clause
10.2.2.1
Public
Text
Class.
Only
XHTML
Host
Language
conforming
documents
should
begin
the
public
text
description
with
the
token
XHTML.
The
public
text
description
should
contain
the
string
XHTML
if
the
document
type
is
Integration
Set
conforming.
The
field
must
also
contain
an
organization-defined
unique
identifier
(e.g.,
MyML
1.0).
This
identifier
should
be
composed
of
a
unique
name
and
a
version
identifier
that
can
be
updated
as
the
document
type
evolves.

The
fourth
field
defines
the
language
in
which
the
item
is
developed
(e.g.,
EN
).

Using
these
rules,
the
name
for
an
XHTML
Host
Language
conforming
document
type
might
be
-//MyCompany//DTD
XHTML
MyML
1.0//EN
.
The
name
for
an
XHTML
family
conforming
module
might
be
-//MyCompany//ELEMENTS
XHTML
MyElements
1.0//EN
.
The
name
for
an
XHTML
Integration
Set
conforming
document
type
might
be
-//MyCompany//DTD
Special
Markup
with
XHTML//EN
.

3.7.
XHTML
Module
Evolution

Each
module
defined
in
this
specification
is
given
a
unique
identifier
that
adheres
to
the
naming
rules
in
the
previous
section.
Over
time,
a
module
may
evolve.
A
logical
ramification
of
such
evolution
may
be
that
some
aspects
of
the
module
are
no
longer
compatible
with
its
previous
definition.
To
help
ensure
that
document
types
defined
against
modules
defined
in
this
specification
continue
to
operate,
the
identifiers
associated
with
a
module
that
changes
will
be
updated.
Specifically,
the
Formal
Public
Identifier
and
System
Identifier
of
the
module
will
be
changed
by
modifying
the
version
identifier
included
in
each.
Document
types
that
wish
to
incorporate
the
updated
functionality
will
need
to
be
similarly
updated.

In
addition,
the
earlier
version(s)
of
the
module
will
continue
to
be
available
via
its
earlier,
unique
identifier(s).
In
this
way,
document
types
developed
using
XHTML
modules
will
continue
to
function
seamlessly
using
their
original
definitions
even
as
the
collection
expands
and
evolves.
Similarly,
document
instances
written
against
such
document
types
will
continue
to
validate
using
the
earlier
module
definitions.

Other
XHTML
Family
Module
and
Document
Type
authors
are
encouraged
to
adopt
a
similar
strategy
to
ensure
the
continued
functioning
of
document
types
based
upon
those
modules
and
document
instances
based
upon
those
document
types.

4.
Defining
Abstract
Modules

This
section
is
normative
.

An
abstract
module
is
a
definition
of
an
XHTML
module
using
prose
text
and
some
informal
markup
conventions.
While
such
a
definition
is
not
generally
useful
in
the
machine
processing
of
document
types,
it
is
critical
in
helping
people
understand
what
is
contained
in
a
module.
This
section
defines
the
way
in
which
XHTML
abstract
modules
are
defined.
An
XHTML-conforming
module
is
not
required
to
provide
an
abstract
module
definition.
However,
anyone
developing
an
XHTML
module
is
encouraged
to
provide
an
abstraction
to
ease
in
the
use
of
that
module.

4.1.
Syntactic
Conventions

The
abstract
modules
are
not
defined
in
a
formal
grammar.
However,
the
definitions
do
adhere
to
the
following
syntactic
conventions.
These
conventions
are
similar
to
those
of
XML
DTDs,
and
should
be
familiar
to
XML
DTD
authors.
Each
discrete
syntactic
element
can
be
combined
with
others
to
make
more
complex
expressions
that
conform
to
the
algebra
defined
here.

element
name

When
an
element
is
included
in
a
content
model,
its
explicit
name
will
be
listed.

content
set

Some
modules
define
lists
of
explicit
element
names
called
content
sets
.
When
a
content
set
is
included
in
a
content
model,
its
name
will
be
listed.

expr
?

Zero
or
one
instances
of
expr
are
permitted.

expr
+

One
or
more
instances
of
expr
are
required.

expr
*

Zero
or
more
instances
of
expr
are
permitted.

a
,
b

Expression
a
is
required,
followed
by
expression
b
.

a
|
b

Either
expression
a
or
expression
b
is
required.

a
-
b

Expression
a
is
permitted,
omitting
elements
in
expression
b.

parentheses

When
an
expression
is
contained
within
parentheses,
evaluation
of
any
subexpressions
within
the
parentheses
take
place
before
evaluation
of
expressions
outside
of
the
parentheses
(starting
at
the
deepest
level
of
nesting
first).

extending
pre-defined
elements

In
some
instances,
a
module
adds
attributes
to
an
element.
In
these
instances,
the
element
name
is
followed
by
an
ampersand
(
&
).

defining
required
attributes

When
an
element
requires
the
definition
of
an
attribute,
that
attribute
name
is
followed
by
an
asterisk
(
*
).

defining
the
type
of
attribute
values

When
a
module
defines
the
type
of
an
attribute
value,
it
does
so
by
listing
the
type
in
parentheses
after
the
attribute
name.

defining
the
legal
values
of
attributes

When
a
module
defines
the
legal
values
for
an
attribute,
it
does
so
by
listing
the
explicit
legal
values
(enclosed
in
quotation
marks),
separated
by
vertical
bars
(
|
),
inside
of
parentheses
following
the
attribute
name.
If
the
attribute
has
a
default
value,
that
value
is
followed
by
an
asterisk
(
*
).
If
the
attribute
has
a
fixed
value,
the
attribute
name
is
followed
by
an
equals
sign
(
=
)
and
the
fixed
value
enclosed
in
quotation
marks.

4.2.
Content
Types

Abstract
module
definitions
define
minimal,
atomic
content
models
for
each
module.
These
minimal
content
models
reference
the
elements
in
the
module
itself.
They
may
also
reference
elements
in
other
modules
upon
which
the
abstract
module
depends.
Finally,
the
content
model
in
many
cases
requires
that
text
be
permitted
as
content
to
one
or
more
elements.
In
these
cases,
the
symbol
used
for
text
is
PCDATA
;
this
is
short
for
"parsed
character
data",
denoting
sequences
of
characters
which
are
to
be
parsed
for
markup
by
an
XML
processor
.(processed
character
data).
A
content
type
can
also
be
defined
as
EMPTY
,
meaning
the
element
has
no
content
in
its
minimal
content
model.

4.3.
Attribute
Types

In
some
instances,
it
is
necessary
to
define
the
types
of
attribute
values
or
the
explicit
set
of
permitted
values
for
attributes.
The
following
attribute
types
(defined
in
the
XML
1.0
Recommendation)
are
used
in
the
definitions
of
the
abstract
modules:

The
attribute
value
type
"Color"
refers
to
color
definitions
as
specified
in
[SRGB]
.
A
color
value
may
either
be
a
hexadecimal
number
(prefixed
by
a
hash
mark)
or
one
of
the
following
sixteen
color
names.
The
color
names
are
case-insensitive.

Color
names
and
sRGB
values

Black
=
"#000000"

Green
=
"#008000"

Silver
=
"#C0C0C0"

Lime
=
"#00FF00"

Gray
=
"#808080"

Olive
=
"#808000"

White
=
"#FFFFFF"

Yellow
=
"#FFFF00"

Maroon
=
"#800000"

Navy
=
"#000080"

Red
=
"#FF0000"

Blue
=
"#0000FF"

Purple
=
"#800080"

Teal
=
"#008080"

Fuchsia
=
"#FF00FF"

Aqua
=
"#00FFFF"

Thus,
the
color
values
"#800080"
and
"Purple"
both
refer
to
the
color
purple.

A
comma-separated
list
of
language
ranges
with
optional
q
parameters,
as
defined
in
section
14.4
of
[
RFC2616
]
as
the
field
value
of
the
Accept-Language
request
header.
Individual
language
codes
should
conform
to
[
BCP47
].

Authors
may
use
the
following
recognized
link
types,
listed
here
with
their
conventional
interpretations.
A
LinkTypes
value
refers
to
a
space-separated
list
of
link
types.
White
space
characters
are
not
permitted
within
link
types.

These
link
types
are
case-insensitive,
i.e.,
"Alternate"
has
the
same
meaning
as
"alternate".

User
agents,
search
engines,
etc.
may
interpret
these
link
types
in
a
variety
of
ways.
For
example,
user
agents
may
provide
access
to
linked
documents
through
a
navigation
bar.

Alternate

Designates
substitute
versions
for
the
document
in
which
the
link
occurs.
When
used
together
with
the
hreflang
attribute,
it
implies
a
translated
version
of
the
document.
When
used
together
with
the
media
attribute,
it
implies
a
version
designed
for
a
different
medium
(or
media).

Stylesheet

Refers
to
an
external
style
sheet.
See
the
Style
Module
for
details.
This
is
used
together
with
the
link
type
"Alternate"
for
user-selectable
alternate
style
sheets.

Start

Refers
to
the
first
document
in
a
collection
of
documents.
This
link
type
tells
search
engines
which
document
is
considered
by
the
author
to
be
the
starting
point
of
the
collection.

Next

Refers
to
the
next
document
in
a
linear
sequence
of
documents.
User
agents
may
choose
to
pre-load
the
"next"
document,
to
reduce
the
perceived
load
time.

Prev

Refers
to
the
previous
document
in
an
ordered
series
of
documents.
Some
user
agents
also
support
the
synonym
"Previous".

Contents

Refers
to
a
document
serving
as
a
table
of
contents.
Some
user
agents
also
support
the
synonym
ToC
(from
"Table
of
Contents").

Index

Refers
to
a
document
providing
an
index
for
the
current
document.

Glossary

Refers
to
a
document
providing
a
glossary
of
terms
that
pertain
to
the
current
document.

Copyright

Refers
to
a
copyright
statement
for
the
current
document.

Chapter

Refers
to
a
document
serving
as
a
chapter
in
a
collection
of
documents.

Section

Refers
to
a
document
serving
as
a
section
in
a
collection
of
documents.

Subsection

Refers
to
a
document
serving
as
a
subsection
in
a
collection
of
documents.

Appendix

Refers
to
a
document
serving
as
an
appendix
in
a
collection
of
documents.

Help

Refers
to
a
document
offering
help
(more
information,
links
to
other
sources
information,
etc.)

Bookmark

Refers
to
a
bookmark.
A
bookmark
is
a
link
to
a
key
entry
point
within
an
extended
document.
The
title
attribute
may
be
used,
for
example,
to
label
the
bookmark.
Note
that
several
bookmarks
may
be
defined
in
each
document.

Authors
may
wish
to
define
additional
link
types
not
described
in
this
specification.
If
they
do
so,
they
should
use
a
profile
to
cite
the
conventions
used
to
define
the
link
types.
Please
see
the
profile
attribute
of
the
head
element
for
more
information.

Intended
for
paged,
opaque
material
and
for
documents
viewed
on
screen
in
print
preview
mode.

braille

Intended
for
braille
tactile
feedback
devices.

aural

Intended
for
speech
synthesizers.

all

Suitable
for
all
devices.

Future
versions
of
XHTML
may
introduce
new
values
and
may
allow
parameterized
values.
To
facilitate
the
introduction
of
these
extensions,
conforming
user
agents
must
be
able
to
parse
the
media
attribute
value
as
follows:

The
value
is
a
comma-separated
list
of
entries.
For
example,

media="screen, 3d-glasses, print and resolution > 90dpi"

is
mapped
to:

"screen"
"3d-glasses"
"print and resolution > 90dpi"

Each
entry
is
truncated
just
before
the
first
character
that
isn't
a
US
ASCII
letter
[a-zA-Z]
(ISO
10646
hex
41-5a,
61-7a),
digit
[0-9]
(hex
30-39),
or
hyphen-minus
(hex
2d).
In
the
example,
this
gives:

"screen"
"3d-glasses"
"print"

A
case-insensitive
match
is
then
made
with
the
set
of
media
types
defined
above.
User
agents
may
ignore
entries
that
don't
match.
In
the
example
we
are
left
with
screen
and
print
.

Note.
Style
sheets
may
include
media-dependent
variations
within
them
(e.g.,
the
CSS
@media
construct).
In
such
cases
it
may
be
appropriate
to
use
"
media
=all"
.

The
value
may
be
a
Length
or
a
relative
length.
A
relative
length
has
the
form
"i*",
where
"i"
is
an
integer.
When
allotting
space
among
elements
competing
for
that
space,
user
agents
allot
pixel
and
percentage
lengths
first,
then
divide
up
remaining
available
space
among
relative
lengths.
Each
relative
length
receives
a
portion
of
the
available
space
that
is
proportional
to
the
integer
preceding
the
"*".
The
value
"*"
is
equivalent
to
"1*".
Thus,
if
60
pixels
of
space
are
available
after
the
user
agent
allots
pixel
and
percentage
space,
and
the
competing
relative
lengths
are
1*,
2*,
and
3*,
the
1*
will
be
allotted
10
pixels,
the
2*
will
be
allotted
20
pixels,
and
the
3*
will
be
allotted
30
pixels.

The
value
is
an
integer
that
represents
the
number
of
pixels
of
the
canvas
(screen,
paper).
Thus,
the
value
"50"
means
fifty
pixels.
For
normative
information
about
the
definition
of
a
pixel,
please
consult
[CSS2]

Script
data
can
be
the
content
of
the
"script"
element
and
the
value
of
intrinsic
event
attributes.
User
agents
must
not
evaluate
script
data
as
HTML
markup
but
instead
must
pass
it
on
as
data
to
a
script
engine.

The
case-sensitivity
of
script
data
depends
on
the
scripting
language.

Please
note
that
script
data
that
is
element
content
may
not
contain
character
references,
but
script
data
that
is
the
value
of
an
attribute
may
contain
them.

This
section
defines
a
sample
abstract
module
as
an
example
of
how
to
take
advantage
of
the
syntax
rules
defined
above.
Since
this
example
is
trying
to
use
all
of
the
various
syntactic
elements
defined,
it
is
pretty
complicated.
Typical
module
definitions
would
be
much
simpler
than
this.
Finally,
note
that
this
module
references
the
attribute
collection
Common.
This
is
a
collection
defined
in
the
XHTML
Modularization
specification
that
includes
all
of
the
basic
attributes
that
most
elements
need.

4.4.1.
XHTML
Skiing
Module

The
XHTML
Skiing
Module
defines
markup
used
when
describing
aspects
of
a
ski
lodge.
The
elements
and
attributes
defined
in
this
module
are:

5.
XHTML
Abstract
Modules

This
section
is
normative
.

This
section
specifies
the
contents
of
the
XHTML
abstract
modules.
These
modules
are
abstract
definitions
of
collections
of
elements,
attributes,
and
their
content
models.
These
abstract
modules
can
be
mapped
onto
any
appropriate
specification
mechanism.
XHTML
DTD
Module
Implementations
,
for
example,
maps
these
modules
onto
DTDs
as
described
in
[XML]
.

Content
developers
and
device
designers
should
view
this
section
as
a
guide
to
the
definition
of
the
functionality
provided
by
the
various
XHTML-defined
modules.
When
developing
documents
or
defining
a
profile
for
a
class
of
documents,
content
developers
can
determine
which
of
these
modules
are
essential
for
conveying
their
message.
When
designing
clients,
device
designers
should
develop
their
device
profiles
by
choosing
from
among
the
abstract
modules
defined
here.

Except
when
overridden
in
this
document,
the
semantics
of
these
elements
and
attributes
are
defined
in
[HTML4]
.

5.1.
Attribute
Collections

Many
of
the
abstract
modules
in
this
section
define
the
required
attributes
for
elements.
The
table
below
defines
some
collections
of
attributes
that
are
referenced
throughout
the
modules.
These
expressions
should
in
no
way
be
considered
normative
or
mandatory.
They
are
an
editorial
convenience
for
this
document.
When
used
in
the
remainder
of
this
section,
it
is
the
expansion
of
the
term
that
is
normative,
not
the
term
itself.

The
following
basic
attribute
sets
are
used
on
many
elements.
In
each
case
where
they
are
used,
their
use
is
identified
via
their
collection
name
rather
than
enumerating
the
list.

Each
of
the
attributes
defined
in
an
XHTML
attribute
collection
is
available
for
use
when
their
corresponding
module
is
included
in
an
XHTML
Host
Language
or
an
XHTML
Integration
Set.
In
such
a
situation,
the
attributes
are
available
for
use
in
the
definition
of
elements
that
are
NOT
in
the
XHTML
namespace
when
they
are
referenced
using
their
namespace-qualified
identifier
(e.g.,
xhtml:class
).
The
semantics
of
the
attributes
remain
the
same
regardless
of
whether
they
are
referenced
using
their
qualified
identifier
or
not.
It
is
an
error
to
use
an
XHTML
namespace-qualified
attribute
on
elements
from
the
XHTML
Namespace.

For
the
avoidance
of
doubt,
if
an
attribute
collection
is
referenced
by
an
element's
definition,
and
an
attribute
in
that
collection
is
also
explicitly
referenced
by
that
element's
definition,
this
does
NOT
cause
a
conflict.
It
is
up
to
the
markup
language
schema
implementation
to
update
the
content
models
accordingly.

5.2.
Core
Modules

5.2.1.
Structure
Module

The
Structure
Module
defines
the
major
structural
elements
for
XHTML.
These
elements
effectively
act
as
the
basis
for
the
content
model
of
many
XHTML
family
document
types.
The
elements
and
attributes
included
in
this
module
are:

This
module
is
the
basic
structural
definition
for
XHTML
content.
The
html
element
acts
as
the
root
element
for
all
XHTML
Family
Document
Types.

Note
that
the
value
of
the
xmlns
attribute
is
defined
to
be
"http://www.w3.org/1999/xhtml".
Also
note
that
because
the
xmlns
attribute
is
treated
specially
by
XML
namespace-aware
parsers
[
XMLNAMES
],
it
is
legal
to
have
it
present
as
an
attribute
of
each
element.
However,
any
time
the
xmlns
attribute
is
used
in
the
context
of
an
XHTML
module,
whether
with
a
prefix
or
not,
the
value
of
the
attribute
shall
be
the
XHTML
namespace
defined
here.
See
Defining
the
Namespace
of
a
Module
for
more
on
rules
regarding
namespace
usage
with
XHTML
family
modules.

When
this
module
is
used,
the
hr
element
is
added
to
the
Block
content
set
of
the
Text
Module.
In
addition,
the
b,
big,
i,
small,
sub,
sup,
and
tt
elements
are
added
to
the
Inline
content
set
of
the
Text
Module.

5.6.2.
Tables
Module

As
its
name
suggests,
the
Tables
Module
provides
table-related
elements
that
are
better
able
to
be
accessed
by
non-visual
user
agents.
Specifically,
the
Tables
Module
supports
the
following
elements,
attributes,
and
content
model:

5.8.
Client-side
Image
Map
Module

The
Client-side
Image
Map
Module
provides
elements
for
client
side
image
maps.
It
requires
that
the
Image
Module
(or
another
module
that
supports
the
img
element)
be
included.
The
Client-side
Image
Map
Module
supports
the
following
elements:

5.9.
Server-side
Image
Map
Module

The
Server-side
Image
Map
Module
provides
support
for
image-selection
and
transmission
of
selection
coordinates.
It
requires
that
the
Image
Module
(or
another
module
that
supports
the
img
element)
be
included.
The
Server-side
Image
Map
Module
supports
the
following
attributes:

5.12.
Target
Module

The
content
of
a
frame
can
specify
destination
targets
for
a
selection.
This
module
adds
the
target
attribute
to
the
area
and
link
defining
elements.
This
is
defined
as
a
separate
module
so
it
can
be
included
in
documents
that
will
be
included
in
frames
and
documents
that
use
the
target
feature
to
open
a
new
window.

5.14.
Intrinsic
Events
Module

Intrinsic
events
are
attributes
that
are
used
in
conjunction
with
elements
that
can
have
specific
events
occur
when
certain
actions
are
performed
by
the
user.
The
attributes
indicated
in
the
following
table
are
added
to
the
attribute
set
for
their
respective
elements
only
when
the
modules
defining
those
elements
are
selected.
Note
also
that
selection
of
this
module
defines
the
attribute
collection
Events
as
described
above.
Attributes
defined
by
this
module
are:

5.16.
Scripting
Module

The
Scripting
Module
defines
elements
that
are
used
to
contain
information
pertaining
to
executable
scripts
or
the
lack
of
support
for
executable
scripts.
Elements
and
attributes
included
in
this
module
are:

When
this
module
is
used,
the
script
and
noscript
elements
are
added
to
the
Block
and
Inline
content
sets
of
the
Text
Module.
In
addition,
the
script
element
is
added
to
the
content
model
of
the
head
element
defined
in
the
Structure
Module.

5.18.
Style
Attribute
Module

5.19.
Link
Module

The
Link
Module
defines
an
element
that
can
be
used
to
define
links
to
external
resources.
These
resources
are
often
used
to
augment
the
user
agent's
ability
to
process
the
associated
XHTML
document.
The
element
and
attributes
included
in
this
module
are:

5.21.
Name
Identification
Module

This
module
is
deprecated.

The
Name
Identification
Module
defines
the
attribute
name
for
a
collection
of
elements.
The
name
attribute
was
used
historically
to
identify
certain
elements
within
HTML
documents.
While
the
name
attribute
has
been
supplanted
by
the
id
attribute
in
all
of
these
elements,
there
may
be
instances
where
markup
languages
will
wish
to
support
both.
Such
markup
languages
may
do
so
by
including
this
module.

Note
that
by
including
this
module,
both
the
name
and
id
attributes
are
defined
for
the
elements
indicated.
In
this
situation,
if
the
name
attribute
is
defined
for
an
element,
the
id
attribute
must
also
be
defined.
Further,
these
attributes
must
both
have
the
same
value.
Finally,
when
documents
that
use
this
attribute
are
served
as
Internet
Media
Type
"text/xml"
or
"application/xml",
the
value
of
the
name
attribute
on
these
elements
shall
not
be
used
as
a
fragment
identifier.

5.22.
Legacy
Module

This
module
is
deprecated.

The
Legacy
Module
defines
elements
and
attributes
that
were
already
deprecated
in
previous
versions
of
HTML
and
XHTML,
and
remain
deprecated
in
XHTML
Modularization.
Markup
language
authors
should
no
longer
use
these
elements
and
attributes.

Note:
This
module
is
not
intended
to
reproduce
all
of
the
deprecated
elements,
attributes,
and
content
models.
Just
those
that
were
thought
to
be
of
maximal
use
at
the
time
this
specification
was
written.

The
following
table
defines
the
elements
and
attributes
that
are
defined
when
the
Legacy
Module
is
selected.

A.
Building
Schema
Modules

This
appendix
is
normative
.

XHTML
modules
are
implemented
as
XML
Schemas.
When
these
XML
Schemas
are
assembled
in
a
specific
manner
(described
in
Developing
Schemas
with
defined
and
extended
modules
),
the
resulting
Schema
is
a
representation
of
a
complete
document
type.
This
representation
can
then
be
used
for
validation
of
instances
of
the
document
type.

The
key
to
combining
these
schema
components
into
a
meaningful,
cohesive
schema
is
the
rules
used
to
define
the
individual
XML
Schemas.
This
section
defines
those
rules.
When
these
rules
are
followed,
markup
language
authors
can
be
confident
that
their
modules
will
interface
cleanly
with
other
XHTML-compatible
modules.

Modules
conforming
to
these
rules
also
need
to
satisfy
the
conformance
requirements
defined
in
XHTML
Family
Module
Conformance
in
order
to
be
called
XHTML
Family
Modules
.

A.1.
Named
Content
Models

This
specification
classifies
named
content
model
into
categories
and
names
them
consistently
using
the
following
suffixes

.content

model
group
definitions
use
the
suffix
.content
when
they
are
used
to
represent
the
content
model
of
an
element
type.

.class

model
group
definitions
use
the
suffix
.class
when
they
are
used
to
represent
elements
of
the
same
class.

.mix

model
group
definitions
use
the
suffix
.mix
when
they
are
used
to
represent
a
collection
of
element
types
from
different
classes.

.extra

model
group
definitions
use
the
suffix
.extra
when
they
are
used
to
extend
other
groups
above.

.export

model
group
definitions
add
the
suffix
.export
when
they
are
to
be
used
by
a
host
language
as
the
basis
for
extending
the
related
content
model
(e.g.,
xhtml.Flow.mix
could
have
an
xhtml.Flow.mix.export
that
defines
a
collection
of
elements
that
must
be
included
in
a
redefinition
of
the
xhtml.Flow.mix
by
a
host
language.

.type

named
complex
type
definitions
use
the
suffix
.type
when
they
are
used
to
represent
type
of
an
element.
Types
usually
include
the
.attlist
and
.content
components.

.attlist

attribute
groups
use
the
suffix
.attlist
when
they
are
used
to
represent
the
attributes
for
a
specific
element.

.attrib

attribute
groups
use
the
suffix
.attrib
when
they
are
used
to
represent
a
group
of
tokens
representing
one
or
more
complete
attribute
specifications
within
an
.attlist
declaration.

For
example,
in
HTML
4,
the
%block;
parameter
entity
is
defined
to
represent
the
heterogeneous
collection
of
element
types
that
are
block-level
elements.
In
this
specification,
the
corollary
named
content
model
is
xhtml.Block.mix
.

When
defining
named
content
models
in
the
classes
defined
here,
modules
should
scope
the
names
of
the
model
group
definitions
and
attribute
groups
by
using
unique
prefixes
(this
recommendation
uses
the
prefix
xhtml.
).
For
example,
the
content
model
for
the
element
myelement
in
the
module
mymodule
could
be
named
mymodule.myelement.content
.
Other
schemes
are
possible.
Regardless
of
the
scheme
used,
module
authors
should
strive
to
ensure
that
named
content
model
they
define
are
named
uniquely
so
that
they
do
not
collide
with
other
named
content
model
and
so
that
the
interface
methods
for
the
module
are
obvious
to
its
users.

A.2.
Defining
the
Namespace
of
a
Module

XHTML
requires
that
the
elements
and
attributes
declared
in
a
module
be
within
a
defined
XML
namespace
[XMLNAMES]
.
The
identification
of
this
namespace
is
an
arbitrary
URI.
XHTML
does
not
require
that
a
module
declare
its
target
namespace
using
the
targetnamespace
attribute.
XHTML
Modularization
using
XML
Schema
has
adopted
a
"late
binding"
approach
to
associating
with
a
namespace.
This
permits
the
development
of
so-called
"chameleon"
modules,
where
the
elements
and
attributes
of
a
module
can
be
incorporated
into
more
than
one
namespace.

A.2.1.
Global
and
Local
Element
Declarations

While
XML
Schema
allows
an
the
definition
of
global
and
local
element
declarations,
to
be
compatible
with
DTD
definitions
of
XHTML
Modularization
module
implementations
must
not
declare
local
elements.

A.2.2.
Global
and
Local
Attribute
Declarations

While
the
approach
defined
here
permits
the
definition
of
global
as
well
as
local
attribute
declarations,
schema
authors
should
consider
the
consequences
of
such
definitions
on
an
document
instance.
Global
attributes
must
always
be
explicitly
prefixed
in
a
instance
document
by
declaring
a
namespace
prefix
xmlns:prefix
,
while
local
attributes
depending
on
the
schema
implementation
may
be
explicitly
prefixed.

A.3.
Importing
External
Namespace
Schema
Components

An
XML
Schema
provides
definitions
that
belong
to
a
given
target
namespace.
A
schema
must
use
the
import
element
to
include
components
from
an
XML
Schema
that
uses
a
different
target
namespace.
The
import
element
in
XML
Schema
requires
a
namespace
attribute
and
a
optional
schemaLocation
attribute.
Multiple
modules
(included
in
a
document
type)
importing
components
from
the
same
external
namespace
but
providing
different
schema
location
URI
values
will
result
in
invalid
driver
schema.
To
avoid
such
issues
modularization
requires
that
modules
importing
external
schemas
must
not
provide
a
schemaLocation
attribute
so
that
a
document
type's
driver
file
may
import
these
schemas
with
the
schemaLocation
attribute.

A.4.
Datatype
Definitions
and
Namespaces

While
the
elements
and
attributes
of
a
module
should
NOT
be
in
a
namespace
until
they
are
used
by
a
markup
language,
the
datatypes
that
a
module
relies
upon
may
need
to
be.
This
is
especially
important
if
the
datatypes
are
to
be
shared
with
other
markup
languages.
If
your
module
has
datatypes
that
you
want
to
share
with
other
modules,
you
should
define
a
namespace
for
those
datatypes,
place
the
datatype
definitions
in
a
separate
"module"
and
bind
that
module
to
the
namespace.
In
XHTML
Modularization,
for
example,
we
use
the
namespace
http://www.w3.org/1999/xhtml/datatypes/
.

A.5.
Content
Model
Redefinitions

Quite
often
modules
change
the
content
model
of
elements
defined
by
other
modules.
For
example,
the
XHTML
Events
module
adds
event
attributes
to
elements
defined
by
the
forms
module.
It
is
also
possible
that
multiple
modules
may
change
the
content
model
of
a
single
element
defined
by
a
third
module,
for
example
both
XHTML
Events
Module
and
XHTML
Image
Map
module
add
attributes
to
elements
in
form
module.

XML
Schemas
allows
for
changes
to
a
declared
content
model
using
the
redefine
element.
While
XML
Schema
supports
the
use
of
a
redefine
element
that
redefines
the
named
content
model
and
type
definition,
XML
Schema
does
not
directly
support
redefinition
of
an
element
or
attribute
declaration.

To
support
element
content
model
redefinitions,
all
content
models
are
defined
with
a
.content
identifier.
This
identifier
can
be
easily
redefined
when
creating
a
driver
module.

Schema
module
implementations
must
define
the
content
model
of
an
element
using
named
complex
types
schema
component
.type
.
Further
the
named
schema
types
must
be
defined
in
terms
of
named
content
model
.content
and
.attlist

redefine
in
XML
Schema
by
default
includes
the
referenced
schema.
Since
the
instantiation
of
a
module
is
decided
by
document
type's
driver
file,
the
module
implementations
must
not
directly
redefine
the
content
model
of
other
modules
in
its
implementation.

Modules
that
expect
to
have
their
content
model
defined
or
extended
by
the
host
language
must
define
a
special
.export
group
for
each
element
or
content
class
that
needs
to
have
its
content
model
extended.
Host
languages
will
use
this
.export
group
as
the
basis
for
the
content
model
of
an
element,
extending
it
with
whatever
additional
content
is
appropriate.
elements
that

B.
Developing
Schema
with
defined
and
extended
modules

This
appendix
is
informative
.

The
primary
purpose
of
defining
XHTML
modules
and
a
general
modularization
methodology
is
to
ease
the
development
of
document
types
that
are
based
upon
XHTML
using
XML
Schemas.
These
document
types
may
extend
XHTML
by
integrating
additional
capabilities
(e.g.,
[SMIL]
),
or
they
may
define
a
subset
of
XHTML
for
use
in
a
specialized
device.
This
section
describes
the
techniques
that
document
type
designers
must
use
in
order
to
take
advantage
of
the
XML
Schema
implementation
of
this
modularization
architecture.
It
does
this
by
applying
the
XHTML
Modularization
techniques
in
progressively
more
complex
ways,
culminating
in
the
creation
of
a
complete
document
type
from
disparate
modules.

Note
that
in
no
case
do
these
examples
require
the
modification
of
the
XHTML-provided
module
file
entities
themselves.
The
XHTML
module
file
entities
are
completely
parameterized,
so
that
it
is
possible
through
separate
module
definitions
and
driver
files
to
customize
the
definition
and
the
content
model
of
each
element
and
each
element's
hierarchy.

Finally,
remember
that
most
users
of
XHTML
are
not
expected
to
be
XML
Schema
authors.
XML
Schema
authors
are
generally
people
who
are
defining
specialized
markup
that
will
improve
the
readability,
simplify
the
rendering
of
a
document,
or
ease
machine-processing
of
documents,
or
they
are
client
designers
that
need
to
define
the
specialized
markup
language
for
their
specific
client.
Consider
these
cases:

An
organization
is
providing
subscriber's
information
via
a
Web
interface.
The
organization
stores
its
subscriber
information
in
an
XML-based
database.
One
way
to
report
that
information
out
from
the
database
to
the
Web
is
to
embed
the
XML
records
from
the
database
directly
in
the
XHTML
document.
While
it
is
possible
to
merely
embed
the
records,
the
organization
could
define
a
module
that
describes
the
records,
attach
that
module
to
an
XHTML
implementation,
and
thereby
create
a
complete
markup
language
for
the
pages.
The
organization
can
then
access
the
data
within
the
new
elements
via
the
Document
Object
Model
[DOM]
,
validate
the
documents,
provide
style
definitions
for
the
elements
that
cascade
using
Cascading
Style
Sheets
[CSS2]
,
etc.
By
taking
the
time
to
define
the
structure
of
their
data
and
create
a
markup
language
using
the
processes
defined
in
this
section,
the
organization
can
realize
the
full
benefits
of
XML.

An
Internet
client
developer
is
designing
a
specialized
device.
That
device
will
only
support
a
subset
of
XHTML,
and
the
devices
will
always
access
the
Internet
via
a
proxy
server
that
validates
content
before
passing
it
on
to
the
client
(to
minimize
error
handling
on
the
client).
In
order
to
ensure
that
the
content
is
valid,
the
developer
creates
a
markup
language
that
is
a
subset
of
XHTML
using
the
processes
defined
in
this
section.
They
then
use
the
new
language
definition
in
their
proxy
server
and
in
their
devices,
and
also
make
the
language
definition
available
to
content
developers
so
that
developers
can
validate
their
content
before
making
it
available.
By
performing
a
few
simple
steps,
the
client
developer
can
use
the
architecture
defined
in
this
document
to
greatly
ease
their
language
development
cost
and
ensure
that
they
are
fully
supporting
the
subset
of
XHTML
that
they
choose
to
include.

B.1.
Defining
additional
attributes

In
some
cases,
an
extension
to
XHTML
can
be
as
simple
as
additional
attributes.
Schema
authors
should
an
provide
the
attribute
definitions
for
each
attribute,
for
example:

would
declare
an
attribute
"myattr"
and
attribute
group
"myattrs.attrib"
in
the
target
namespace
of
the
schema
("xs"
is
the
prefix
for
XML
Schema
Namespace).
Authors
should
note
that
the
attribute
is
created
as
local
attribute
(as
part
attribute
group).
Alternatively,
declaring
an
attribute
by
placing
the
attribute
declaration
as
direct
child
of
schema
element
would
create
a
Global
attribute
(and
document
instances
would
have
to
use
qualified
attribute
name
such
as
xlink:show).
For
a
discussion
of
qualified
names
and
Namespace
prefixes,
see
Defining
the
Namespace
of
a
Module
.

To
add
this
attribute
to
the
content
model
of
an
element,
the
attribute
group
(that
makes
the
content
model
of
the
element)
would
need
to
be
redefined
(by
the
document
type's
driver
file)
to
include
the
new
attribute.
for
example:

The
target
namespace
of
the
attribute
group
definition
is
not
XHTML
namespace
and
must
be
contained
in
a
separate
XML
schema.

Naturally,
adding
an
attribute
to
a
schema
does
not
mean
that
any
new
behavior
is
defined
for
arbitrary
clients.
However,
a
content
developer
could
use
an
extra
attribute
to
store
information
that
is
accessed
by
associated
scripts
via
the
Document
Object
Model
(for
example).

B.2.
Defining
additional
elements

Defining
additional
elements
is
similar
to
attributes,
but
a
typical
XHTML
module
would
define
the
element
as
a
global
element
(as
a
direct
child
of
schema
element).
Schema
authors
should
first
provide
the
element
declaration
for
each
element:

The
target
namespace
of
"myelement"
declared
is
not
XHTML
namespace,
hence
must
be
contained
in
a
separate
XML
Schema.
"xs"
is
the
prefix
for
XML
Schema
Namespace.
After
the
elements
are
defined,
they
need
to
be
integrated
into
the
content
model.
Strategies
for
integrating
new
elements
or
sets
of
elements
into
the
content
model
are
addressed
in
the
next
section.

B.3.
Defining
the
content
model
for
a
collection
of
modules

Since
the
content
model
of
XHTML
modules
is
fully
parameterized
using
named
content
models,
Schema
authors
may
modify
the
content
model
for
every
element
in
every
module.
The
details
of
the
schema
module
interface
are
defined
in
Building
Schema
Modules
.
Basically
there
are
two
ways
to
approach
this
modification:

Re-define
the
named
content
model,
.content
,
for
each
element.

Define
one
or
more
of
the
global
named
content
model
entities
to
include
the
element
in
those
named
model
definitions
(normally
via
the
named
content
model,
.extras
).

The
strategy
taken
will
depend
upon
the
nature
of
the
modules
being
combined
and
the
nature
of
the
elements
being
integrated.
The
remainder
of
this
section
describes
techniques
for
integrating
two
different
classes
of
modules.

B.3.1.
Integrating
a
stand-alone
module
into
XHTML

When
a
module
(and
remember,
a
module
can
be
a
collection
of
other
modules)
contains
elements
that
only
reference
each
other
in
their
content
model,
it
is
said
to
be
"internally
complete".
As
such,
the
module
can
be
used
on
its
own;
(for
example,
you
could
define
a
schema
that
was
just
that
module,
and
use
one
of
its
elements
as
the
root
element).
Integrating
such
a
module
into
XHTML
is
a
three
step
process:

Decide
what
element(s)
can
be
thought
of
as
the
root(s)
of
the
new
module.

Decide
where
these
elements
need
to
attach
in
the
XHTML
content
tree.

Then,
for
each
attachment
point
in
the
content
tree,
add
the
root
element(s)
to
the
content
definition
for
the
XHTML
elements.

Consider
attaching
the
elements
defined
above
.
In
that
example,
the
element
myelement
is
the
root.
To
attach
this
element
under
the
img
element,
and
only
the
img
element,
of
XHTML,
the
following
redefinition
would
work:

Such
redefinition
must
not
be
included
in
the
module
implementation,
but
instead
provided
as
part
of
the
document
type's
driver
implementation.
A
schema
defined
with
this
content
model
would
allow
a
document
like
the
following
fragment:

It
is
important
to
note
that
normally
the
img
element
has
a
content
model
of
EMPTY
.
By
adding
myelement
to
that
content
model,
we
are
really
just
replacing
EMPTY
with
myelement
.
In
the
case
of
other
elements
that
already
have
content
models
defined,
the
addition
of
an
element
would
require
the
restating
of
the
existing
content
model
in
addition
to
myelement
.

B.3.2.
Mixing
a
new
module
throughout
the
modules
in
XHTML

Extending
the
example
above,
to
attach
this
module
everywhere
that
the
%Flow.mix
content
model
group
is
permitted,
would
require
something
like
the
following
in
the
schema
that
defines
the
document
model
of
the
document
type:

Since
the
Misc.extra
content
model
class
is
used
in
the
content
model
the
named
model
Misc.class,
and
that
named
model
is
used
throughout
the
XHTML
modules,
the
new
module
would
become
available
throughout
an
extended
XHTML
document
type.

B.4.
Creating
a
new
Document
Type

So
far
the
examples
in
this
section
have
described
the
methods
of
extending
XHTML
and
XHTML's
content
model.
Once
this
is
done,
the
next
step
is
to
collect
the
modules
that
comprise
the
Document
Type
into
a
schema
driver
and
schema
file
that
provides
the
content
model
redefinitions
of
included
modules,
incorporating
the
new
definitions
so
that
they
override
and
augment
the
basic
XHTML
definitions
as
appropriate.

B.4.1.
Creating
a
simple
Document
Type

Using
the
trivial
example
above,
it
is
possible
to
define
a
new
schema
that
uses
and
extends
the
XHTML
modules
pretty
easily.
First,
define
the
new
elements
and
their
content
model
in
a
module:

B.4.2.
Creating
a
Language
by
extending
XHTML

Next,
there
is
the
situation
where
a
complete,
additional,
and
complex
module
is
added
to
XHTML
(or
to
a
subset
of
XHTML).
In
essence,
this
is
the
same
as
in
the
example
above,
the
only
difference
being
that
the
module
being
added
is
incorporated
in
the
schema
by
creating
an
new
document
model
schema.

One
such
complex
module
is
the
Schema
for
[MATHML]
.
In
order
to
combine
MathML
and
XHTML
into
a
single
Schema,
an
author
would
just
decide
where
MathML
content
should
be
legal
in
the
document,
and
add
the
MathML
root
element
to
the
content
model
at
that
point.
First,
define
a
new
document
model
that
instantiates
the
MathML
Schema
and
connects
it
to
the
content
XHTML
content
model
by
redefining
the
XHTML
content
model.
Providing
a
redefinition
of
the
XHTML
content
model
by
implication
includes
the
XHTML
content
model
in
the
new
document
content
model
:

B.4.3.
Creating
a
Language
by
removing
and
replacing
XHTML
modules

Another
way
in
which
Schema
authors
may
use
XHTML
modules
is
to
define
a
Schema
that
is
a
subset
of
an
XHTML
family
document
type
(because,
for
example,
they
are
building
devices
or
software
that
only
supports
a
subset
of
XHTML).
To
do
this
simple
create
a
Schema
driver
that
does
not
include
the
relevant
modules.
Schema
author
should
note
that
redefine
in
schema
by
default
includes
all
the
content
model
of
the
referenced
schema,
authors
should
also
not
include
any
redefinitions
of
modules
that
they
do
not
wish
to
include.
The
basic
steps
to
follow
are:

Take
an
XHTML
family
Schema
as
the
basis
of
the
new
document
type
(e.g.
XHTML
1.1).

Select
the
modules
to
remove
from
that
Schema.

Physically,
remove
include
and
redefine
schema
elements
that
include
any
non
relevant
modules
from
the
driver
file.
Also
references
to
schema
components
from
such
modules
used
in
redefinitions
of
other
modules
must
be
deleted.

Introduce
some
new
modules

B.4.4.
Creating
a
the
new
Document
Type

Finally,
some
Schema
authors
may
wish
to
start
from
scratch,
using
the
XHTML
Modularization
framework
as
a
toolkit
for
building
a
new
markup
language.
This
language
must
be
made
up
of
the
minimal,
required
modules
from
XHTML.
It
may
also
contain
other
XHTML-defined
modules
or
any
other
module
that
the
author
wishes
to
employ.
In
this
example,
we
will
take
the
XHTML
required
modules,
add
some
XHTML-defined
modules,
and
also
add
in
the
module
we
defined
above.

The
first
step
is
to
define
a
module
that
defines
the
elements
and
attributes
using
the
provided
template
.

Now,
build
a
content
model
description
that
hooks
the
new
elements
and
attributes
into
the
other
XHTML
elements.
The
following
example
is
patterned
after
the
XHTML
Basic
content
model,
but
is
a
complete,
free-standing
content
model
module:

Finally,
build
a
driver
schema.
For
ease
of
extensibility
this
driver
schema
is
split
into
two
XML
Schema
files.
The
first
file
of
driver
schema
collects
(includes)
all
the
modules
needed
for
the
new
document
type.
This
schema
also
provides
the
required
redefinitions
of
schema
components
in
included
modules.(Note:
in
XML
Schema
redefine
includes
the
schema
referenced.

The
second
file
of
the
driver
schema
builds
new
document
type
based
the
content
model
and
modules.
Also
this
schema
provides
the
schemaLocation
for
all
imported
namespaces
(namespaces
imported
by
the
included
modules)

C.
XHTML
Schema
Module
Implementations

This
appendix
is
normative
.

This
appendix
contains
implementations
of
the
modules
defined
in
XHTML
Abstract
Modules
via
XML
Schemas.
These
module
implementations
can
be
used
by
XHTML
Family
Document
Types.
There
are
direct
links
to
the
various
files,
and
the
files
are
also
contained
in
the
"Gzip'd
TAR"
and
"Zip"
archives
linked
to
at
the
top
of
this
document.
Please
note
that
the
files
targeted
by
the
"latest
version"
links
may
change
slowly
over
time.
See
the
W3C
XHTML2
Working
Group
home
page
for
more
information.

C.1.
Character
Entities

XML
Schema
uses
DTDs
to
support
character
entities.
The
DTD
implementation
of
XHTML
Modularization
[XHTMLMOD]
defines
the
required
character
entities
for
XHTML.
The
schema
implementation
includes
the
set
of
character
entities
for
XHTML,
including
the
Latin
1,
Symbol
and
Special
character
collections
defined
as
part
the
DTD
implementation
of
XHTML
Modularization
[XHTMLMOD].

Even
though
the
named
character
entities
are
defined
using
DTDs
and
included
in
the
Schema
Modularization
Framework,
schema
processors
typically
do
not
expand
the
named
character
entities
in
an
XML
document
instance.
The
html
DOCTYPE
declaration
must
still
be
present
if
one
wishes
to
use
named
entities
defined
by
this
Framework
module

C.2.
XHTML
Schema
Modular
Framework

The
Framework
modules
instantiates
a
set
of
support
model
that
define
the
common
Datatypes,
Notations,
Common
attribute
definitions
and
character
entities.
These
are
defined
in
a
set
of
support
modules,
instantiated
by
a
main
Framework
module:

<?xml version="1.0" encoding="UTF-8"?>
<!--
This schema module includes three named character entity files.
-->
<!DOCTYPE xs:schema [
<!-- These are the entity sets for ISO Latin 1 characters for the XHTML -->
<!ENTITY % HTMLlat1 PUBLIC
"-//W3C//ENTITIES Latin 1 for XHTML//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-lat1.ent">
%HTMLlat1;
<!-- These are the entity sets for special characters for the XHTML -->
<!ENTITY % HTMLsymbol PUBLIC
"-//W3C//ENTITIES Symbols for XHTML//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-symbol.ent">
%HTMLsymbol;
<!-- These are the entity sets for symbol characters for the XHTML -->
<!ENTITY % HTMLspecial PUBLIC
"-//W3C//ENTITIES Special for XHTML//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-special.ent">
%HTMLspecial;
]>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:annotation>
<xs:documentation>
Character Entities for XHTML
This is the XML Schema Character Entities module for XHTML
This module declares the set of character entities for XHTML,
including the Latin 1, Symbol and Special character collections.
XML Schema does not support Entities, hence Entities are enable
through an Internal DTD Subset.
$Id: xhtml-charent-1.xsd,v 1.3 2005/09/26 22:54:53 ahby Exp $
</xs:documentation>
<xs:documentation source="xhtml-copyright-1.xsd"/>
</xs:annotation>
</xs:schema>

C.3.
XHTML
Module
Implementations

This
section
contains
the
formal
definition
of
each
of
the
XHTML
Abstract
Modules
as
a
Schema
module.

C.4.
XHTML
Schema
Support
Modules

The
modules
in
this
section
are
elements
of
the
XHTML
Schema
implementation
that,
while
hidden
from
casual
users,
are
important
to
understand
when
creating
derivative
markup
languages
using
the
Modularization
architecture.

D.
Building
DTD
Modules

This
section
is
normative.

XHTML
modules
are
implemented
as
DTD
fragments.
When
these
fragments
are
assembled
in
a
specific
manner
(described
in
Developing
DTDs
with
defined
and
extended
modules
),
the
resulting
DTD
is
a
representation
of
a
complete
document
type.
This
representation
can
then
be
used
for
validation
of
instances
of
the
document
type.

The
key
to
combining
these
fragments
into
a
meaningful
DTD
is
the
rules
used
to
define
the
fragments.
This
section
defines
those
rules.
When
these
rules
are
followed,
DTD
authors
can
be
confident
that
their
modules
will
interface
cleanly
with
other
XHTML-compatible
modules.

Modules
conforming
to
these
rules
also
need
to
satisfy
the
conformance
requirements
defined
in
XHTML
Family
Module
Conformance
in
order
to
be
called
XHTML
Family
Modules
.

D.1.
Parameter
Entity
Naming

This
specification
classifies
parameter
entities
into
seven
categories
and
names
them
consistently
using
the
following
suffixes:

.mod

parameter
entities
use
the
suffix
.mod
when
they
are
used
to
represent
a
DTD
module
(a
collection
of
elements,
attributes,
parameter
entities,
etc).
In
this
specification,
each
module
is
an
atomic
unit
and
may
be
represented
as
a
separate
file
entity.

.module

parameter
entities
use
the
suffix
.module
when
they
are
used
to
control
the
inclusion
of
a
DTD
module
by
containing
either
of
the
conditional
section
keywords
INCLUDE
or
IGNORE
.

.qname

parameter
entities
use
the
suffix
.qname
when
they
are
used
to
represent
the
qualified
name
of
an
element.
See
Defining
the
Namespace
of
a
Module
for
more
information
on
qualified
names.

.content

parameter
entities
use
the
suffix
.content
when
they
are
used
to
represent
the
content
model
of
an
element
type.

.class

parameter
entities
use
the
suffix
.class
when
they
are
used
to
represent
elements
of
the
same
class.

.mix

parameter
entities
use
the
suffix
.mix
when
they
are
used
to
represent
a
collection
of
element
types
from
different
classes.

.attrib

parameter
entities
use
the
suffix
.attrib
when
they
are
used
to
represent
a
group
of
tokens
representing
one
or
more
complete
attribute
specifications
within
an
ATTLIST
declaration.

For
example,
in
HTML
4,
the
%block;
parameter
entity
is
defined
to
represent
the
heterogeneous
collection
of
element
types
that
are
block-level
elements.
In
this
specification,
the
corollary
parameter
entity
is
%Block.mix;
.

When
defining
parameter
entities
in
the
classes
defined
here,
modules
should
scope
the
names
of
the
entities
by
using
unique
prefixes.
For
example,
the
content
model
for
the
element
myelement
in
the
module
mymodule
could
be
named
MYMODULE.myelement.content
.
Other
schemes
are
possible.
Regardless
of
the
scheme
used,
module
authors
should
strive
to
ensure
that
parameter
entities
they
define
are
named
uniquely
so
that
they
do
not
collide
with
other
parameter
entities
and
so
that
the
interface
methods
for
the
module
are
obvious
to
its
users.

D.2.
Defining
the
Namespace
of
a
Module

XHTML
requires
that
the
elements
and
attributes
declared
in
a
module
be
within
a
defined
XML
namespace
[XMLNAMES]
.
The
identification
of
this
namespace
is
an
arbitrary
URI.
XHTML
requires
that
when
a
module
is
implemented
using
an
XML
DTD,
the
module
declares
the
namespace
in
a
special
manner.
The
purpose
of
this
is
to
permit
the
selection,
at
document
parse/validation
time,
of
the
use
of
namespace
prefixes
and
of
the
prefix
that
is
used
to
identify
elements
and
attributes
from
the
module.

Content
developers
who
wish
to
develop
documents
based
upon
hybrid
document
types
may
choose
to
use
XML
namespace
prefixes
on
elements
from
the
XHTML
namespace,
on
elements
from
other
namespaces,
or
on
both.
In
order
to
ensure
that
such
documents
are
XHTML
conforming
and
backward
compatible
with
non-namespace
aware
tools,
the
W3C
recommends
that
content
developers
do
not
use
XML
namespace
prefixes
on
elements
from
the
XHTML
namespace.
When
content
developers
are
interested
in
having
their
content
processed
by
namespace-aware
processors,
the
W3C
further
recommends
that
elements
in
non-XHTML
namespaces
be
specified
using
an
XML
namespace
prefix
rather
than
relying
upon
XML
namespace
defaulting
mechanisms.

Each
XHTML-conforming
module
implemented
as
an
XML
DTD
is
required
to
define
a
default
XML
namespace
prefix,
a
method
for
changing
this
prefix
within
a
document
instance,
and
a
marked
section
that
turns
on
the
processing
of
the
prefix.

Note
that
it
is
legal
and
expected
for
multiple
modules
to
be
part
of
the
same
namespace
when
they
are
related.
All
of
the
XHTML
modules,
for
example,
are
part
of
the
same
namespace.

D.2.1.
Qualified
Names
sub-module

First,
you
need
to
define
a
qualified
names
sub-module
(a
sub-module
is
just
a
file
entity
that
is
separated
so
that
it
can
be
incorporated
into
the
ultimate
DTD
at
the
appropriate
point).
The
qualified
names
sub-module
is
built
using
the
following
steps
(where
the
string
MODULE
is
replaced
with
an
appropriate
string
for
the
new
module):

Define
a
parameter
entity
MODULE.prefixed
that
announces
whether
the
elements
in
the
module
are
being
used
with
XML
namespace
prefixed
names
or
not.
This
parameter
entity's
default
value
should
be
"%NS.prefixed;".
The
NS.prefixed
parameter
entity
is
defined
by
the
XHTML
framework
to
be
IGNORE
by
default,
and
can
be
used
in
a
document
instance
to
switch
on
prefixing
for
all
included
namespaces
(including
that
of
the
XHTML
modules).

Define
a
parameter
entity
MODULE.xmlns
that
contains
the
namespace
identifier
for
this
module.

Define
a
parameter
entity
MODULE.prefix
that
contains
the
default
prefix
string
to
use
when
prefixing
is
enabled.

Define
a
parameter
entity
MODULE.pfx
that
is
"%MODULE.prefix;:"
when
prefixing
is
enabled,
and
""
when
it
is
not.

Define
a
parameter
entity
MODULE.xmlns.extra.attrib
that
contains
the
declaration
of
any
XML
namespace
attributes
for
namespaces
referenced
by
this
module
(e.g.,
xmlns:xlink).
When
%MODULE.prefixed
is
set
to
INCLUDE,
this
attribute
should
include
the
xmlns:%MODULE.prefix;
declaration
as
well.

Define
a
parameter
entity
XHTML.xmlns.extra.attrib
as
MODULE.xmlns.extra.attrib.
This
is
usually
overridden
by
the
document
type's
driver
file,
but
if
not
this
definition
will
take
over
as
the
default.

For
each
of
the
elements
defined
by
the
module,
create
a
parameter
entity
of
the
form
"MODULE.NAME.qname"
to
hold
its
qualified
name.
The
value
for
this
parameter
entity
must
be
"%MODULE.pfx;NAME".
In
this
way,
the
parsed
value
will
be
"PREFIX:NAME"
when
prefixes
are
enabled,
and
"NAME"
otherwise.

If
the
module
adds
attributes
to
elements
defined
in
modules
that
do
not
share
the
namespace
of
this
module,
declare
those
attributes
so
that
they
use
the
%MODULE.pfx
prefix.
For
example:

<ENTITY % MODULE.img.myattr.qname "%MODULE.pfx;myattr" >

An
example
of
a
qname
sub-module
for
a
hypothetical
Inventory
Module
is
included
below:

D.2.2.
Declaration
sub-module(s)

Next,
you
need
to
define
one
or
more
"declaration
sub-modules".
The
purpose
of
these
file
entities
is
to
declare
the
XML
DTD
elements
and
attribute
lists.
An
XHTML
declaration
module
should
be
constructed
using
the
following
process:

Define
a
parameter
entity
to
use
within
the
ATTLIST
of
each
declared
element.
This
parameter
entity
should
contain
%NS.decl.attrib;
when
%MODULE.prefixed;
is
set
to
INCLUDE,
and
%NS.decl.attrib;
plus
"xmlns
%URI.datatype;
#FIXED
'%MODULE.xmlns;'"
when
%MODULE.prefixed;
is
set
to
IGNORE.

Declare
all
of
the
elements
and
attributes
for
the
module.
Within
each
ATTLIST
for
an
element,
include
the
parameter
entity
defined
above
so
that
all
of
the
required
xmlns
attributes
are
available
on
each
element
in
the
module.

If
the
module
adds
attributes
to
elements
defined
in
modules
that
do
not
share
the
namespace
of
this
module,
declare
those
attributes
so
that
they
use
the
%MODULE.pfx
prefix.
For
example:

This
would
add
an
attribute
to
the
img
element
of
the
Image
Module,
but
the
attribute's
name
will
be
the
qualified
name,
including
prefix,
when
prefixes
are
selected
for
a
document
instance.
It
also
adds
the
xmlns:MODULE_PREFIX
attribute
to
the
img
element's
attribute
list
so
that
an
XML
Namespace-aware
parser
would
know
how
to
resolve
the
namespace
based
upon
its
prefix.

The
following
example
shows
a
declaration
sub-module
for
a
hypothetical
Inventory
module.

D.2.3.
Using
the
module
as
a
stand-alone
DTD

It
is
sometimes
desirable
to
have
an
XHTML
module
also
usable
as
a
stand
alone
DTD.
A
good
example
of
this
is
our
Inventory
module
above.
These
items
need
to
be
embeddable
in
an
XHTML
document,
and
also
need
to
be
available
as
free-standing
documents
extracted
from
a
database
(for
example).
The
easiest
way
to
accomplish
this
is
to
define
a
DTD
file
that
instantiates
the
components
of
your
module.
Such
a
DTD
would
have
this
structure:

Include
the
XHTML
Datatypes
Module
(your
qnames
module
likely
uses
some
of
these
datatypes
-
it
certainly
uses
the
URI
datatype
for
the
xmlns
attribute).

Include
the
Qnames
Module
for
your
module.

Define
the
parameter
entity
NS.decl.attrib
to
be
%MODULE.xmlns.extra.attrib;.

<!DOCTYPE shelf SYSTEM "inventory-1.dtd">
<shelf xmlns="http://www.example.com/xmlns/inventory">
<item>
<desc>
this is a description.
</desc>
<sku>
this is the price.
</sku>
<price>
this is the price.
</price>
</item>
</shelf>

This
method
permits
the
definition
of
elements
and
attributes
that
are
scoped
within
their
own
namespace.
It
also
permits
content
developers
to
use
the
default
prefix
for
the
elements
and
attributes:

D.2.4.
Namespace
Idiosyncrasies

While
the
approach
defined
here
permits
the
definition
of
markup
languages
that
are
XML
and
XML
namespaces
conforming,
some
behaviors
defined
by
the
XML
namespaces
specification
are
not
supported:

XML
namespaces
permit
the
redeclaration
of
the
xmlns
attribute
for
a
namespace
at
any
point
in
the
tree.
It
further
permits
this
redeclaration
to
switch
between
namespace
defaulting
and
prefixed
usage,
and
permits
the
changing
of
the
prefix.
The
method
defined
in
this
document
does
not
permit
this.
Throughout
a
document
instance
a
given
namespace
must
continue
to
use
the
same
namespace
prefix
(when
prefixing
is
used),
or
must
continue
to
be
used
in
the
default
scope.

When
using
XML
namespace
defaulting,
it
is
legal
to
rely
upon
the
DTD
of
the
document
to
inform
parsers
of
the
namespace
of
elements.
However,
since
namespace
aware
processors
are
not
required
to
include
the
DTD
when
evaluating
a
document,
content
developers
should
declare
the
XML
namespace
of
an
element
whenever
the
namespace
changes:

...
<p>
<myelement xmlns="..." />
</p>

E.
Developing
DTDs
with
defined
and
extended
modules

This
section
is
informative
.

The
primary
purpose
of
defining
XHTML
modules
and
a
general
modularization
methodology
is
to
ease
the
development
of
document
types
that
are
based
upon
XHTML.
These
document
types
may
extend
XHTML
by
integrating
additional
capabilities
(e.g.,
[SMIL]
),
or
they
may
define
a
subset
of
XHTML
for
use
in
a
specialized
device.
This
section
describes
the
techniques
that
document
type
designers
must
use
in
order
to
take
advantage
of
the
XML
DTD
implementation
of
this
modularization
architecture.
It
does
this
by
applying
the
XHTML
Modularization
techniques
in
progressively
more
complex
ways,
culminating
in
the
creation
of
a
complete
document
type
from
disparate
modules.

Note
that
in
no
case
do
these
examples
require
the
modification
of
the
XHTML-provided
module
file
entities
themselves.
The
XHTML
module
file
entities
are
completely
parameterized,
so
that
it
is
possible
through
separate
module
definitions
and
driver
files
to
customize
the
definition
and
the
content
model
of
each
element
and
each
element's
hierarchy.

Finally,
remember
that
most
users
of
XHTML
are
not
expected
to
be
DTD
authors.
DTD
authors
are
generally
people
who
are
defining
specialized
markup
that
will
improve
the
readability,
simplify
the
rendering
of
a
document,
or
ease
machine-processing
of
documents,
or
they
are
client
designers
that
need
to
define
the
specialized
DTD
for
their
specific
client.
Consider
these
cases:

An
organization
is
providing
subscriber's
information
via
a
Web
interface.
The
organization
stores
its
subscriber
information
in
an
XML-based
database.
One
way
to
report
that
information
out
from
the
database
to
the
Web
is
to
embed
the
XML
records
from
the
database
directly
in
the
XHTML
document.
While
it
is
possible
to
merely
embed
the
records,
the
organization
could
define
a
DTD
module
that
describes
the
records,
attach
that
module
to
an
XHTML
DTD,
and
thereby
create
a
complete
DTD
for
the
pages.
The
organization
can
then
access
the
data
within
the
new
elements
via
the
Document
Object
Model
[DOM]
,
validate
the
documents,
provide
style
definitions
for
the
elements
that
cascade
using
Cascading
Style
Sheets
[CSS2]
,
etc.
By
taking
the
time
to
define
the
structure
of
their
data
and
create
a
DTD
using
the
processes
defined
in
this
section,
the
organization
can
realize
the
full
benefits
of
XML.

An
Internet
client
developer
is
designing
a
specialized
device.
That
device
will
only
support
a
subset
of
XHTML,
and
the
devices
will
always
access
the
Internet
via
a
proxy
server
that
validates
content
before
passing
it
on
to
the
client
(to
minimize
error
handling
on
the
client).
In
order
to
ensure
that
the
content
is
valid,
the
developer
creates
a
DTD
that
is
a
subset
of
XHTML
using
the
processes
defined
in
this
section.
They
then
use
the
new
DTD
in
their
proxy
server
and
in
their
devices,
and
also
make
the
DTD
available
to
content
developers
so
that
developers
can
validate
their
content
before
making
it
available.
By
performing
a
few
simple
steps,
the
client
developer
can
use
the
architecture
defined
in
this
document
to
greatly
ease
their
DTD
development
cost
and
ensure
that
they
are
fully
supporting
the
subset
of
XHTML
that
they
choose
to
include.

E.1.
Defining
additional
attributes

In
some
cases,
an
extension
to
XHTML
can
be
as
simple
as
additional
attributes.
Attributes
can
be
added
to
an
element
just
by
specifying
an
additional
ATTLIST
for
the
element,
for
example:

would
add
the
"myattr"
attribute,
with
an
optional
prefix
defined
by
"%MyModule.pfx",
with
a
value
type
of
CDATA,
to
the
"a"
element.
This
works
because
XML
permits
the
definition
or
extension
of
the
attribute
list
for
an
element
at
any
point
in
a
DTD.
For
a
discussion
of
qualified
names
and
namespace
prefixes,
see
Defining
the
Namespace
of
a
Module
.

Naturally,
adding
an
attribute
to
a
DTD
does
not
mean
that
any
new
behavior
is
defined
for
arbitrary
clients.
However,
a
content
developer
could
use
an
extra
attribute
to
store
information
that
is
accessed
by
associated
scripts
via
the
Document
Object
Model
(for
example).

E.2.
Defining
additional
elements

Defining
additional
elements
is
only
slightly
more
complicated
than
defining
additional
attributes.
Basically,
DTD
authors
should
write
the
element
declaration
for
each
element:

After
the
elements
are
defined,
they
need
to
be
integrated
into
the
content
model.
Strategies
for
integrating
new
elements
or
sets
of
elements
into
the
content
model
are
addressed
in
the
next
section.

E.3.
Defining
the
content
model
for
a
collection
of
modules

Since
the
content
model
of
XHTML
modules
is
fully
parameterized,
DTD
authors
may
modify
the
content
model
for
every
element
in
every
module.
The
details
of
the
DTD
module
interface
are
defined
in
Building
DTD
Modules
.
Basically
there
are
two
ways
to
approach
this
modification:

Re-define
the
".content"
parameter
entity
for
each
element.

Re-define
one
or
more
of
the
global
content
model
entities
(normally
via
the
".extras"
parameter
entity).

The
strategy
taken
will
depend
upon
the
nature
of
the
modules
being
combined
and
the
nature
of
the
elements
being
integrated.
The
remainder
of
this
section
describes
techniques
for
integrating
two
different
classes
of
modules.

E.3.1.
Integrating
a
stand-alone
module
into
XHTML

When
a
module
(and
remember,
a
module
can
be
a
collection
of
other
modules)
contains
elements
that
only
reference
each
other
in
their
content
model,
it
is
said
to
be
"internally
complete".
As
such,
the
module
can
be
used
on
its
own;
(for
example,
you
could
define
a
DTD
that
was
just
that
module,
and
use
one
of
its
elements
as
the
root
element).
Integrating
such
a
module
into
XHTML
is
a
three
step
process:

Decide
what
element(s)
can
be
thought
of
as
the
root(s)
of
the
new
module.

Decide
where
these
elements
need
to
attach
in
the
XHTML
content
tree.

Then,
for
each
attachment
point
in
the
content
tree,
add
the
root
element(s)
to
the
content
definition
for
the
XHTML
elements.

Consider
attaching
the
elements
defined
above
.
In
that
example,
the
element
myelement
is
the
root.
To
attach
this
element
under
the
img
element,
and
only
the
img
element,
of
XHTML,
the
following
would
work:

<!ENTITY % img.content "( %MyModule.myelement.qname; )*">

A
DTD
defined
with
this
content
model
would
allow
a
document
like
the
following
fragment:

It
is
important
to
note
that
normally
the
img
element
has
a
content
model
of
EMPTY
.
By
adding
myelement
to
that
content
model,
we
are
really
just
replacing
EMPTY
with
myelement
.
In
the
case
of
other
elements
that
already
have
content
models
defined,
the
addition
of
an
element
would
require
the
restating
of
the
existing
content
model
in
addition
to
myelement
.

E.3.2.
Mixing
a
new
module
throughout
the
modules
in
XHTML

Extending
the
example
above,
to
attach
this
module
everywhere
that
the
%Flow.mix
content
model
group
is
permitted,
would
require
something
like
the
following:

<!ENTITY % Misc.extra
"| %MyModule.myelement.qname;" >

Since
the
%Misc.extra
content
model
class
is
used
in
the
%Misc.class
parameter
entity,
and
that
parameter
entity
is
used
throughout
the
XHTML
modules,
the
new
module
would
become
available
throughout
an
extended
XHTML
document
type.

E.4.
Creating
a
new
DTD

So
far
the
examples
in
this
section
have
described
the
methods
of
extending
XHTML
and
XHTML's
content
model.
Once
this
is
done,
the
next
step
is
to
collect
the
modules
that
comprise
the
DTD
into
a
single
DTD
driver,
incorporating
the
new
definitions
so
that
they
override
and
augment
the
basic
XHTML
definitions
as
appropriate.

E.4.1.
Creating
a
simple
DTD

Using
the
trivial
example
above,
it
is
possible
to
define
a
new
DTD
that
uses
and
extends
the
XHTML
modules
pretty
easily.
First,
define
the
new
elements
and
their
content
model
in
a
module:

E.4.2.
Creating
a
DTD
by
extending
XHTML

Next,
there
is
the
situation
where
a
complete,
additional,
and
complex
module
is
added
to
XHTML
(or
to
a
subset
of
XHTML).
In
essence,
this
is
the
same
as
in
the
trivial
example
above,
the
only
difference
being
that
the
module
being
added
is
incorporated
in
the
DTD
by
reference
rather
than
explicitly
including
the
new
definitions
in
the
DTD.

One
such
complex
module
is
the
DTD
for
[MATHML]
.
In
order
to
combine
MathML
and
XHTML
into
a
single
DTD,
an
author
would
just
decide
where
MathML
content
should
be
legal
in
the
document,
and
add
the
MathML
root
element
to
the
content
model
at
that
point.
First,
define
a
content
model
module
that
instantiates
the
MathML
DTD
and
connects
it
to
the
content
model:

E.4.3.
Creating
a
DTD
by
removing
and
replacing
XHTML
modules

Another
way
in
which
DTD
authors
may
use
XHTML
modules
is
to
define
a
DTD
that
is
a
subset
of
an
XHTML
family
document
type
(because,
for
example,
they
are
building
devices
or
software
that
only
supports
a
subset
of
XHTML).
Doing
this
is
only
slightly
more
complex
than
the
previous
example.
The
basic
steps
to
follow
are:

Take
an
XHTML
family
DTD
as
the
basis
of
the
new
document
type
(we
will
use
XHTML
1.1).

Select
the
modules
to
remove
from
that
DTD.

Define
a
new
DTD
that
"IGNOREs"
the
modules.

Introduce
some
new
modules.

For
example,
consider
a
device
that
uses
XHTML
modules,
but
without
forms
or
tables.
The
DTD
for
such
a
device
would
look
like
this:

Note
that
this
does
not
actually
modify
the
content
model
for
the
XHTML
1.1
DTD.
However,
since
XML
ignores
elements
in
content
models
that
are
not
defined,
the
form
and
table
elements
are
dropped
from
the
model
automatically.

E.4.4.
Creating
a
new
DTD

Finally,
some
DTD
authors
may
wish
to
start
from
scratch,
using
the
XHTML
Modularization
framework
as
a
toolkit
for
building
a
new
markup
language.
This
language
must
be
made
up
of
the
minimal,
required
modules
from
XHTML.
It
may
also
contain
other
XHTML-defined
modules
or
any
other
module
that
the
author
wishes
to
employ.
In
this
example,
we
will
take
the
XHTML
required
modules,
add
some
XHTML-defined
modules,
and
also
add
in
the
module
we
defined
above.

The
first
step
is
to
use
the
XHTML-provided
template
for
a
new
qualified
names
module,
modified
to
define
the
qualified
names
and
namespace
for
our
new
elements.

Now,
build
a
content
model
description
that
hooks
the
new
elements
and
attributes
into
the
other
XHTML
elements.
The
following
example
is
patterned
after
the
XHTML
Basic
content
model,
but
is
a
complete,
free-standing
content
model
module:

F.
XHTML
DTD
Module
Implementations

This
appendix
is
normative
.

This
appendix
contains
implementations
of
the
modules
defined
in
XHTML
Abstract
Modules
via
XML
DTDs.
These
module
implementations
can
be
used
by
XHTML
Family
Document
Types.
There
are
direct
links
to
the
various
files,
and
the
files
are
also
contained
in
the
"Gzip'd
TAR"
and
"Zip"
archives
linked
to
at
the
top
of
this
document.
Please
note
that
the
files
targeted
by
the
"latest
version"
links
may
change
slowly
over
time.
See
the
W3C
XHTML2
Working
Group
home
page
for
more
information.

F.1.
XHTML
Character
Entities

XHTML
DTDs
make
available
a
standard
collection
of
named
character
entities.
Those
entities
are
defined
in
this
section.

F.2.
XHTML
Modular
Framework

In
order
to
take
advantage
of
the
XHTML
DTD
Modules,
DTD
authors
need
to
define
the
content
model
for
their
DTD.
XHTML
provides
a
variety
of
tools
to
ease
this
effort.
They
are
defined
in
a
set
of
support
modules,
instantiated
by
a
main
Framework
module:

Note
that
the
module
above
references
a
content
model
module.
This
module
is
defined
on
a
per-document
type
basis
in
addition
to
the
document
type
driver
file.
The
Modular
framework
also
relies
upon
the
following
component
modules:

F.4.
XHTML
DTD
Support
Modules

The
modules
in
this
section
are
elements
of
the
XHTML
DTD
implementation
that,
while
hidden
from
casual
users,
are
important
to
understand
when
creating
derivative
markup
languages
using
the
Modularization
architecture.

"
Information
Technology
--
Universal
Multiple-Octet
Coded
Character
Set
(UCS)
",
ISO/IEC
10646:2003,
as,
from
time
to
time,
amended,
replaced
by
a
new
edition
or
expanded
by
the
addition
of
new
parts.
(See
http://www.iso.org/iso/en/ISOOnline.openerpage
for
the
latest
version.)

H.
Design
Goals

In
this
appendix,
design
goals
are
identified
with
a
label
"Gn",
and
requirements
are
identified
with
a
label
"Rn.n".
There
are
four
major
design
goals
for
the
modularization
framework
for
XHTML:

[G1]
To
group
semantically
related
parts
of
XHTML
together.

[G2]
Using
DTD
technology,
to
support
the
creation
of
related
languages
(subsets,
supersets)
for
specific
purposes
(small
devices,
special-purpose
devices),
while
guaranteeing
commonality
of
the
overlapping
parts.

[G3]
To
facilitate
future
development
by
allowing
parts
of
the
language
to
be
replaced
by
improved
modules
(for
instance,
forms)
without
disturbing
the
rest
of
the
language.

[G4]
To
encourage
and
facilitate
the
reuse
of
modules
in
other
languages.

H.1.
Requirements

The
design
goals
listed
in
the
previous
section
lead
to
a
large
number
of
requirements
for
the
modularization
framework.
These
requirements,
summarized
in
this
section,
can
be
further
classified
according
to
the
major
features
of
the
framework
to
be
described.

H.1.1.
Granularity

Collectively
the
requirements
in
this
section
express
the
desire
that
the
modules
defined
within
the
framework
hit
the
right
level
of
granularity:

[R1.7]
Modules
should
be
small
enough
to
allow
single
element
document
type
modules.

H.1.2.
Composibility

The
composibility
requirements
listed
here
are
intended
to
ensure
that
the
modularization
framework
be
able
to
express
the
right
set
of
target
modules
required
by
the
communities
that
will
be
served
by
the
framework:

[R2.1]
The
module
framework
should
allow
construction
of
abstract
modules
for
XHTML
1.0.

[R2.3]
The
module
framework
should
allow
construction
of
abstract
modules
for
other
W3C
Recommendations.

[R2.4]
The
module
framework
should
allow
construction
of
abstract
modules
for
other
XML
document
types.

[R2.5]
The
module
framework
should
allow
construction
of
abstract
modules
for
a
wide
range
of
platform
profiles.

H.1.3.
Ease
of
Use

The
modularization
framework
will
only
receive
widespread
adoption
if
it
describes
mechanisms
that
make
it
easy
for
our
target
audience
to
use
the
framework:

[R3.1]
The
module
framework
should
make
it
easy
for
document
type
designers
to
subset
and
extend
XHTML
abstract
modules.

[R3.2]
The
module
framework
should
make
it
easy
for
document
type
designers
to
create
abstract
modules
for
other
XML
document
types.

[R3.3]
The
module
framework
should
make
it
easy
for
document
authors
to
validate
elements
from
different
abstract
modules.

H.1.4.
Compatibility

The
intent
of
this
document
is
that
the
modularization
framework
described
here
should
work
well
with
the
XML
and
other
standards
being
developed
by
the
W3C
Working
Groups:

[R4.1]
The
module
framework
should
strictly
conform
to
the
XML
1.0
Recommendation.

[R4.2]
The
module
framework
should
be
compatible
with
the
XML
Linking
Language
(XLink)
[XLINK]
specification.

[R4.3]
The
module
framework
should
be
compatible
with
the
Associating
Style
Sheets
with
XML
documents
[XMLSTYLE]
specification.

[R4.4]
The
module
framework
should
be
able
to
adopt
new
W3C
Recommendations
where
appropriate.

[R4.5]
The
module
framework
should
not
depend
on
W3C
work
in
progress.

[R4.6]
The
module
framework
should
not
depend
on
work
done
outside
W3C.

H.1.5.
Conformance

The
effectiveness
of
the
framework
will
also
be
measured
by
how
easy
it
is
to
test
the
behavior
of
modules
developed
according
to
the
framework,
and
to
test
the
documents
that
employ
those
modules
for
validation:

[R5.1]
It
should
be
possible
to
validate
documents
constructed
using
elements
and
attributes
from
abstract
modules.

[R5.2]
It
should
be
possible
to
explicitly
describe
the
behavior
of
elements
and
attributes
from
abstract
modules.

[R5.3]
It
should
be
possible
to
verify
the
behavior
of
elements
and
attributes
from
abstract
modules.

[R5.4]
It
should
be
possible
to
verify
a
hybrid
document
type
as
an
XHTML
document
type.

[R5.5]
Modules
defined
in
accordance
with
the
methods
in
this
document
shall
not
duplicate
the
names
of
elements
or
parameter
entities
defined
in
XHTML
modules.

J.
Acknowledgements

This
appendix
is
informative
.

This
specification
was
prepared
by
the
W3C
XHTML
2
Working
Group.
The
members
at
the
time
of
publication
of
version
1.0
were:

Steven
Pemberton,
CWI
(
HTML
Working
Group
Chair)

Murray
Altheim,
Sun
Microsystems

Daniel
Austin,
Mozquito
Technologies

Jonny
Axelsson,
Opera
Software

Mark
Baker,
Sun
Microsystems

Wayne
Carr,
Intel

Tantek
Çelik,
Microsoft

Doug
Dominiak,
Openwave
Systems

Andrew
W.
Donoho,
IBM

Herman
Elenbaas,
Philips
Electronics

Beth
Epperson,
Netscape/
AOL

Masayasu
Ishikawa,
W3C
(
HTML
Activity
Lead)

Shin'ichi
Matsui,
Panasonic

Shane
McCarron,
Applied
Testing
and
Technology

Ann
Navarro,
WebGeek,
Inc.

Peter
Stark,
Ericsson

Michel
Suignard,
Microsoft

Jeremy
Wadsworth,
Quark
Inc.

Malte
Wedel,
Mozquito
Technologies

Ted
Wugofski,
Openwave
Systems

The
contributors
to
the
original
Modularization
of
XHTML
in
XML
Schema
effort
were:

I.
Changes
from
XHTML
Modularization
1.0

This
appendix
is
informative
.

This
specification
supercedes
XHTML
Modularization
1.0
.
This
section
describes
at
a
high
level
the
changes
from
that
version.
This
section
does
not
attempt
to
address
the
various
editorial
corrections
that
were
made.
For
a
detailed
comparison,
see
the
"diff
marked"
version
from
that
recommendation.

Global
Changes

Introduction
of
an
XML
Schema
implementation.
This
includes
the
development
of
a
Modularization
technique
to
be
used
with
XML
Schema,
and
the
actual
implementation
of
the
abstract
modules
using
that
technique.

Clarified
that
in
XHTML
Family
Languages
the
"default"
behavior
of
XML
whitespace
processing
is
"preserve"
as
defined
in
[
XML
].

Section
2
-
Terms
and
Definitions

Added
a
definition
of
the
term
"facilities".

Section
3
-
Conformance
Definition

Clarified
that
attributes
from
the
XHTML
namespace
can
be
used
on
elements
NOT
in
the
XHTML
namespace,
but
they
should
be
namespace-qualified.

Clarified
the
rules
for
processing
of
unrecognized
elements
in
conforming
user
agents.