W3C

Modularization of XHTML ™ 1.0 - Second Edition

W3C Working Draft 18 February 2004

This version:
http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218
Latest version:
http://www.w3.org/TR/xhtml-modularization
Previous version:
http://www.w3.org/TR/2003/WD-xhtml-m12n-schema-20031003
http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410
Diff-marked version:
xhtml-modularization-diff.html
Second Edition Editors:
Daniel Austin , Sun Microsystems
Subramanian Peruvemba, Oracle Corporation
Shane McCarron , Applied Testing and Technology, Inc.
Masayasu Ishikawa , W3C
Editors:
Murray Altheim , Sun Microsystems
Frank Boumphrey , HTML Writers Guild
Sam Dooley , IBM
Shane McCarron , Applied Testing and Technology
Sebastian Schnitzenbaumer, Mozquito Technologies AG
Ted Wugofski , Openwave (formerly Gateway)

This document is also available in these non-normative formats: Single HTML file , PostScript version , PDF version , ZIP archive , or Gzip'd TAR archive .

See also translations .

Copyright ©2001-2004 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark , document use and software licensing rules apply.

Abstract

This document is the second edition of Modularization of XHTML, 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. The second edition of this document provides several minor updates to provide clarifications and address errors found in the first edition.

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 is a working draft, but is nearly complete. It reflects clarifications and corrections as a result of nearly three years of use by the community. It also includes an new implementation of the abstract modules using XML Schemas. This implementation has gone through the W3C process, including Last Call, and is now integrated here in anticipation of its publication as a W3C Recommendation. It should in no way be considered stable, and should not be normatively referenced for any purposes whatsoever. It is being published so that the community can review the changes in anticipation of entering the W3C's Proposed Edited Recommendation process later this year.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document has been produced by the W3C HTML Working Group ( members only ) as part of the W3C HTML Activity . The goals of the HTML Working Group are discussed in the HTML Working Group charter . The W3C staff contact for work on HTML is Masayasu Ishikawa . Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page .

Public discussion of HTML takes place on www-html@w3.org ( archive ). To subscribe send an email to www-html-request@w3.org with the word subscribe in the subject line.

Please report errors in this document to www-html-editor@w3.org ( archive ).

The English version of this specification is the only normative version. Information about translations of this document is available at http://www.w3.org/MarkUp/translations.

Quick Table of Contents

Full Table of Contents

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 Document Type Definition language, but an implementation using XML Schemas is expected. The rules for defining the abstract modules, and for implementing them using 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.

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

1.3.3. Hybrid document types

A hybrid document type is an document type composed from a collection of XML DTDs or DTD Modules. The primary purpose of the modularization framework described in this document is to allow a DTD 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 document type definition.

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.

A document is an instance of one particular document type defined by the DTD identified in the document's prologue. Validating the document is the process of checking that the document complies with the rules in the document type definition.

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 document type definitions to be integrated and form a new document type (e.g. SVG integrated into XHTML). The new document type definition 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.
entity reference
a mnemonic string used as a reference to the content of a declared entity (eg., "&amp;" for "&", "&lt;" for "<", "&copy;" for "©".)
facilities
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:

  1. 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.
  2. The schema which defines the document type must have a unique identifier as defined in Naming Rules that uses the string "XHTML" in its first token of the public text description.
  3. The schema which defines the document type must include, at a minimum, the Structure, Hypertext, Text, and List modules defined in this specification.
  4. 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.
  5. 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 MUST be referenced using their namespace-qualified identifier (e.g., xhtml:id). 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:

  1. 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.
  2. The schema that defines the document type must have a unique identifier as defined in Naming Rules that uses the string "XHTML" NOT in its first token of the public text description.
  3. The schema which defines the document type must include, at a minimum, the Hypertext, Text, and List modules defined in this specification.
  4. 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.
  5. 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 MUST be referenced using their namespace-qualified identifier (e.g., xhtml:id). 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:

  1. 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.
  2. The schema that defines the module must have a unique identifier as defined in Naming Rules .
  3. When the module is defined using an XML DTD, the module must insulate its parameter entity names through the use of unique prefixes or other, similar methods.
  4. 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.
  5. 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 namespace (see below).
  6. 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.

3.5. XHTML Family User Agent Conformance

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

  1. 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.
  2. 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.
  3. When a user agent processes an XHTML document as generic [XML] , it shall only recognize attributes of type ID (e.g., the id attribute on most XHTML elements) as fragment identifiers.
  4. If a user agent encounters an element it does not recognize, it must continue to process the children of that element. If the content is text, the text must be presented to the user.
  5. 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).
  6. If a user agent encounters an attribute value it doesn't recognize, it must use the default attribute value.
  7. 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.
  8. 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.
  9. Whitespace is defined as in [XML] . On input all whitespace is preserved. 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:

  1. The leading field must be "-" to indicate a privately defined resource.
  2. 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 .
  3. 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.
  4. 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 a term, defined in the XML 1.0 Recommendation, that refers to 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:

Attribute Type Definition
CDATA Character data
ID A document-unique identifier
IDREF A reference to a document-unique identifier
IDREFS A space-separated list of references to document-unique identifiers
NAME A name with the same character constraints as ID above
NMTOKEN A name composed of only name tokens as defined in XML 1.0 [XML]
NMTOKENS One or more white space separated NMTOKEN values
PCDATA Processed character data

In addition to these pre-defined data types, XHTML Modularization defines the following data types and their semantics (as appropriate):

Data type Description
Character A single character from [ISO10646] .
Charset A character encoding, as per [RFC2045] .
Charsets A space-separated list of character encodings, as per [RFC2045] .
Color

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 Swatch Black = "#000000" Green Swatch Green = "#008000"
Silver Swatch Silver = "#C0C0C0" Lime Swatch Lime = "#00FF00"
Gray Swatch Gray = "#808080" Olive Swatch Olive = "#808000"
White Swatch White = "#FFFFFF" Yellow Swatch Yellow = "#FFFF00"
Maroon Swatch Maroon = "#800000" Navy Swatch Navy = "#000080"
Red Swatch Red = "#FF0000" Blue Swatch Blue = "#0000FF"
Purple Swatch Purple = "#800080" Teal Swatch Teal = "#008080"
Fuchsia Swatch Fuchsia = "#FF00FF" Aqua Swatch Aqua = "#00FFFF"

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

ContentType A media type, as per [RFC2045] .
ContentTypes A comma-separated list of media types, as per [RFC2045] .
Coords Comma separated list of coordinates to use in defining areas.
Datetime Date and time information.
FPI A character string representing an SGML Formal Public Identifier.
FrameTarget Frame name used as destination for results of certain actions.
LanguageCode A language code, as per [RFC3066] .
Length The value may be either in pixels or a percentage of the available horizontal or vertical space. Thus, the value "50%" means half of the available space.
LinkTypes

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

The MediaDesc attribute is a comma-separated list of media descriptors. The following is a list of recognized media descriptors:

screen
Intended for non-paged computer screens.
tty
Intended for media using a fixed-pitch character grid, such as teletypes, terminals, or portable devices with limited display capabilities.
tv
Intended for television-type devices (low resolution, color, limited scrollability).
projection
Intended for projectors.
handheld
Intended for handheld devices (small screen, monochrome, bitmapped graphics, limited bandwidth).
print
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:

  1. 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"
  2. 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"
  3. 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" .

MultiLength 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.
MultiLengths A comma separated list of items of type MultiLength .
Number One or more digits
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

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.

Shape The shape of a region.
Text Arbitrary textual data, likely meant to be human-readable.
URI A Uniform Resource Identifier Reference, as defined by the type anyURI in XMLSCHEMA .
URIs A space-separated list of URIs as defined above.

4.4. An Example Abstract Module Definition

This section is informative

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:

Elements Attributes Minimal Content Model
resort Common, href (CDATA) description, Aspen+
lodge Common description, (Aspen - lift)+
lift Common, href description?
chalet Common, href description?
room Common, href description?
lobby Common, href description?
fireplace Common, href description?
description Common PCDATA*

This module also defines the content set Aspen with the minimal content model lodge | lift | chalet | room | lobby | fireplace .

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 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 on elements that are NOT in the XHTML namespace when they are referenced using their namespace-qualified identifier (e.g., xhtml:id ). The semantics of the attributes remain the same regardless of whether they are referenced using their qualified identifier or not. If both the qualified and non-qualified identifier for an attribute are used on the same XHTML namespace element, the behavior is unspecified.

Collection Name Attributes in Collection
Core class ( NMTOKENS ), id ( ID ), title ( CDATA )
I18N xml:lang ( CDATA )
Events onclick ( Script ), ondblclick ( Script ), onmousedown ( Script ), onmouseup ( Script ), onmouseover ( Script ), onmousemove ( Script ), onmouseout ( Script ), onkeypress ( Script ), onkeydown ( Script ), onkeyup ( Script )
Style style ( CDATA )
Common Core + Events + I18N + Style

Note that the Events collection is only defined when the Intrinsic Events Module is selected. Otherwise, the Events collection is empty.

Also note that the Style collection is only defined when the Style Attribute Module is selected. Otherwise, the Style collection is empty.

5.2. Core Modules

The core modules are modules that are required to be present in any XHTML Family Conforming Document Type .

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:

Elements Attributes Minimal Content Model
body Common (Heading | Block | List)*
head I18N , profile ( URI ) title
html I18N , version ( CDATA ), xmlns ( URI = "http://www.w3.org/1999/xhtml") head, body
title I18N PCDATA

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.

Implementation: DTD

5.2.2. Text Module

This module defines all of the basic text container elements, attributes, and their content model:

Element Attributes Minimal Content Model
abbr Common (PCDATA | Inline)*
acronym Common (PCDATA | Inline)*
address Common (PCDATA | Inline)*
blockquote Common , cite ( URI ) (Heading | Block | List)*
br Core EMPTY
cite Common (PCDATA | Inline)*
code Common (PCDATA | Inline)*
dfn Common (PCDATA | Inline)*
div Common (PCDATA | Flow)*
em Common (PCDATA | Inline)*
h1 Common (PCDATA | Inline)*
h2 Common (PCDATA | Inline)*
h3 Common (PCDATA | Inline)*
h4 Common (PCDATA | Inline)*
h5 Common (PCDATA | Inline)*
h6 Common (PCDATA | Inline)*
kbd Common (PCDATA | Inline)*
p Common (PCDATA | Inline)*
pre Common , xml:space="preserve" (PCDATA | Inline)*
q Common , cite ( URI ) (PCDATA | Inline)*
samp Common (PCDATA | Inline)*
span Common (PCDATA | Inline)*
strong Common (PCDATA | Inline)*
var Common (PCDATA | Inline)*

The minimal content model for this module defines some content sets:

Heading
h1 | h2 | h3 | h4 | h5 | h6
Block
address | blockquote | div | p | pre
Inline
abbr | acronym | br | cite | code | dfn | em | kbd | q | samp | span | strong | var
Flow
Heading | Block | Inline

Implementation: DTD

5.2.3. Hypertext Module

The Hypertext Module provides the element that is used to define hypertext links to other resources. This module supports the following element and attributes:

Element Attributes Minimal Content Model
a Common , accesskey ( Character ), charset ( Charset ), href ( URI ), hreflang ( LanguageCode ), rel ( LinkTypes ), rev ( LinkTypes ), tabindex ( Number ), type ( ContentType ) (PCDATA | Inline - a)*

This module adds the a element to the Inline content set of the Text Module.

Implementation: DTD

5.2.4. List Module

As its name suggests, the List Module provides list-oriented elements. Specifically, the List Module supports the following elements and attributes:

Elements Attributes Minimal Content Model
dl Common (dt | dd)+
dt Common (PCDATA | Inline)*
dd Common (PCDATA | Flow)*
ol Common li+
ul Common li+
li Common (PCDATA | Flow)*

This module also defines the content set List with the minimal content model (dl | ol | ul)+ and adds this set to the Flow content set of the Text Module.

Implementation: DTD

5.3. Applet Module

This module is deprecated. Similar functionality can be found in the Object Module .

The Applet Module provides elements for referencing external applications. Specifically, the Applet Module supports the following elements and attributes:

Element Attributes Minimal Content Model
applet Core, alt* ( Text ), archive ( CDATA ), code ( CDATA ), codebase ( URI ), height* ( Length ), object ( CDATA ), width* ( Length ) (PCDATA | Flow | param)*
param id ( ID ), name* ( CDATA ), type ( ContentType ), value ( CDATA ), valuetype ("data"* | "ref" | "object") EMPTY

When the Applet Module is used, it adds the applet element to the Inline content set of the Text Module.

Implementation: DTD

5.4. Text Extension Modules

This section defines a variety of additional textual markup modules.

5.4.1. Presentation Module

This module defines elements, attributes, and a minimal content model for simple presentation-related markup:

Element Attributes Minimal Content Model
b Common (PCDATA | Inline)*
big Common (PCDATA | Inline)*
hr Common EMPTY
i Common (PCDATA | Inline)*
small Common (PCDATA | Inline)*
sub Common (PCDATA | Inline)*
sup Common (PCDATA | Inline)*
tt Common (PCDATA | Inline)*

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.

Implementation: DTD

5.4.2. Edit Module

This module defines elements and attributes for use in editing-related markup:

Element Attributes Minimal Content Model
del Common , cite ( URI ), datetime ( Datetime ) (PCDATA | Flow)*
ins Common , cite ( URI ), datetime ( Datetime ) (PCDATA | Flow)*

When this module is used, the del and ins elements are added to the Inline content set of the Text Module.

Implementation: DTD

5.4.3. Bi-directional Text Module

The Bi-directional Text module defines an element that can be used to declare the bi-directional rules for the element's content.

Elements Attributes Minimal Content Model
bdo Core , dir* ("ltr" | "rtl") (PCDATA | Inline)*

When this module is used, the bdo element is added to the Inline content set of the Text Module. Selecting this module also adds the attribute dir* ("ltr" | "rtl") to the I18N attribute collection.

Implementation: DTD

5.5. Forms Modules

5.5.1. Basic Forms Module

The Basic Forms Module provides the form-related elements, but only in a limited form. Specifically, the Basic Forms Module supports the following elements, attributes, and minimal content model:

Elements Attributes Minimal Content Model
form Common , action* ( URI ), method ("get"* | "post"), enctype ( ContentType ) (Heading | List | Block - form)+
input Common , accesskey ( Character ), checked ("checked"), maxlength ( Number ), name ( CDATA ), size ( Number ), src ( URI ), tabindex ( Number ), type ("text"* | "password" | "checkbox" | "radio" | "submit" | "reset" | "hidden" ), value ( CDATA ) EMPTY
label Common , accesskey ( Character ), for ( IDREF ) (PCDATA | Inline - label)*
select Common , multiple ("multiple"), name ( CDATA ), size ( Number ), tabindex ( Number ) option+
option Common , selected ("selected"), value ( CDATA ) PCDATA
textarea Common , accesskey ( Character ), cols* ( Number ), name ( CDATA ), rows* ( Number ), tabindex ( Number ) PCDATA

This module defines two content sets:

Form
form
Formctrl
input | label | select | textarea

When this module is used, it adds the Form content set to the Block content set and it adds the Formctrl content set to the Inline content set as these are defined in the Text Module.

The Basic Forms Module is a subset of the Forms Module. These modules may not be used together in a single document type.

Implementation: DTD

5.5.2. Forms Module

The Forms Module provides all of the forms features found in HTML 4.0. Specifically, the Forms Module supports:

Elements Attributes Minimal Content Model
form Common , accept ( ContentTypes ), accept-charset ( Charsets ), action* ( URI ), method ("get"* | "post"), enctype ( ContentType ) (Heading | List | Block - form | fieldset)+
input Common , accept ( ContentTypes ), accesskey ( Character ), alt ( Text ), checked ("checked"), disabled ("disabled"), maxlength ( Number ), name ( CDATA ), readonly ("readonly"), size ( Number ), src ( URI ), tabindex ( Number ), type ("text"* | "password" | "checkbox" | "button" | "radio" | "submit" | "reset" | "file" | "hidden" | "image"), value ( CDATA ) EMPTY
select Common , disabled ("disabled"), multiple ("multiple"), name ( CDATA ), size ( Number ), tabindex ( Number ) (optgroup | option)+
option Common , disabled ("disabled"), label ( Text ), selected ("selected"), value ( CDATA ) PCDATA
textarea Common , accesskey ( Character ), cols* ( Number ), disabled ("disabled"), name ( CDATA ), readonly ("readonly"), rows* ( Number ), tabindex ( Number ) PCDATA
button Common , accesskey ( Character ), disabled ("disabled"), name ( CDATA ), tabindex ( Number ), type ("button" | "submit"* | "reset"), value ( CDATA ) (PCDATA | Heading | List | Block - Form | Inline - Formctrl)*
fieldset Common (PCDATA | legend | Flow)*
label Common , accesskey ( Character ), for ( IDREF ) (PCDATA | Inline - label)*
legend Common , accesskey ( Character ) (PCDATA | Inline)*
optgroup Common , disabled ("disabled"), label* ( Text ) option+

This module defines two content sets:

Form
form | fieldset
Formctrl
input | select | textarea | label | button

When this module is used, it adds the Form content set to the Block content set and it adds the Formctrl content set to the Inline content set as these are defined in the Text Module.

The Forms Module is a superset of the Basic Forms Module. These modules may not be used together in a single document type.

Implementation: DTD

5.6. Table Modules

5.6.1. Basic Tables Module

The Basic Tables Module provides table-related elements, but only in a limited form. Specifically, the Basic Tables Module supports:

Elements Attributes Minimal Content Model
caption Common (PCDATA | Inline)*
table Common , width ( Length ), summary ( Text ) caption?, tr+
td Common , abbr ( Text ), align ("left" | "center" | "right"), axis ( CDATA ), colspan ( Number ), headers ( IDREFS ), rowspan ( Number ), scope ("row" | "col"), valign ("top" | "middle" | "bottom") (PCDATA | Flow - table)*
th Common , abbr ( Text ), align ("left" | "center" | "right"), axis ( CDATA ), colspan ( Number ), headers ( IDREFS ), rowspan ( Number ), scope ("row" | "col" ), valign ("top" | "middle" | "bottom") (PCDATA | Flow - table)*
tr Common , align ("left" | "center" | "right"), valign ("top" | "middle" | "bottom") (td | th)+

When this module is used, it adds the table element to the Block content set as defined in the Text Module.

The Basic Tables Module is a subset of the Tables Module. These modules may not be used together in a single document type.

Implementation: DTD

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:

Elements Attributes Minimal Content Model
caption Common (PCDATA | Inline)*
table Common , border ( Pixels ), cellpadding ( Length ), cellspacing ( Length ), frame ("void" | "above" | "below" | "hsides" | "lhs" | "rhs" | "vsides" | "box" | "border"), rules ("none" | "groups" | "rows" | "cols" | "all"), summary ( Text ), width ( Length ) caption?, ( col* | colgroup* ), (( thead?, tfoot?, tbody+ ) | ( tr+ ))
td Common , abbr ( Text ), align ("left" | "center" | "right" | "justify" | "char"), axis ( CDATA ), char ( Character ), charoff ( Length ), colspan ( Number ), headers ( IDREFS ), rowspan ( Number ), scope ("row" | "col" | "rowgroup" | "colgroup"), valign ("top" | "middle" | "bottom" | "baseline") (PCDATA | Flow)*
th Common , abbr ( Text ), align ("left" | "center" | "right" | "justify" | "char"), axis ( CDATA ), char ( Character ), charoff ( Length ), colspan ( Number ), headers ( IDREFS ), rowspan ( Number ), scope ("row" | "col" | "rowgroup" | "colgroup"), valign ("top" | "middle" | "bottom" | "baseline") (PCDATA | Flow)*
tr Common , align ("left" | "center" | "right" | "justify" | "char"), char ( Character ), charoff ( Length ), valign ("top" | "middle" | "bottom" | "baseline") (td | th)+
col Common , align ("left" | "center" | "right" | "justify" | "char"), char ( Character ), charoff ( Length ), span ( Number ), valign ("top" | "middle" | "bottom" | "baseline"), width ( MultiLength ) EMPTY
colgroup Common , align ("left" | "center" | "right" | "justify" | "char"), char ( Character ), charoff ( Length ), span ( Number ), valign ("top" | "middle" | "bottom" | "baseline"), width ( MultiLength ) col*
tbody Common , align ("left" | "center" | "right" | "justify" | "char"), char ( Character ), charoff ( Length ), valign ("top" | "middle" | "bottom" | "baseline") tr+
thead Common , align ("left" | "center" | "right" | "justify" | "char"), char ( Character ), charoff ( Length ), valign ("top" | "middle" | "bottom" | "baseline") tr+
tfoot Common , align ("left" | "center" | "right" | "justify" | "char"), char ( Character ), charoff ( Length ), valign ("top" | "middle" | "bottom" | "baseline") tr+

When this module is used, it adds the table element to the Block content set of the Text Module.

The Tables Module is a superset of the Basic Tables Module. These modules may not be used together in a single document type.

Implementation: DTD

5.7. Image Module

The Image Module provides basic image embedding, and may be used in some implementations independently of client side image maps. The Image Module supports the following element and attributes:

Elements Attributes Minimal Content Model
img Common , alt* ( Text ), height ( Length ), longdesc ( URI ), src* ( URI ), width ( Length ) EMPTY

When this module is used, it adds the img element to the Inline content set of the Text Module.

Implementation: DTD

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:

Elements Attributes Minimal Content Model
a& coords ( CDATA ), shape ("rect" | "circle" | "poly" | "default") n/a
area Common , accesskey ( Character ), alt* ( Text ), coords ( CDATA ), href ( URI ), nohref ("nohref"), shape ("rect"* | "circle" | "poly" | "default"), tabindex ( Number ) EMPTY
img& usemap ( IDREF ) n/a
input& usemap ( IDREF ) Note: Only when the Forms or Basic Forms module is included
map I18N , Events , class ( NMTOKEN ), id* ( ID ), title ( CDATA ) ((Heading | Block) | area)+
object& usemap ( IDREF ) Note: Only when the object module is included

When this module is used, the map element is added to the Inline content set of the Text Module.

Implementation: DTD

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:

Elements Attributes Minimal Content Model Notes
img& ismap ("ismap") n/a  
input& ismap ("ismap") n/a When the Forms or Basic Forms Module is selected.

Implementation: DTD

5.10. Object Module

The Object Module provides elements for general-purpose object inclusion. Specifically, the Object Module supports:

Elements Attributes Minimal Content Model
object Common , archive ( URIs ), classid ( URI ), codebase ( URI ), codetype ( ContentType ), data ( URI ), declare ("declare"), height ( Length ), name ( CDATA ), standby ( Text ), tabindex ( Number ), type ( ContentType ), width ( Length ) (PCDATA | Flow | param)*
param id ( ID ), name* ( CDATA ), type ( ContentType ), value ( CDATA ), valuetype ("data"* | "ref" | "object") EMPTY

When this module is used, it adds the object element to the Inline content set of the Text Module.

Implementation: DTD

5.11. Frames Module

As its name suggests, the Frames Module pr