Modularization of XHTML
™W3C Recommendation 10 April 2001
This version:
http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410
(Single HTML file [p.1] , PostScript version, PDF version, ZIP archive, or Gzip’d TAR archive)
Latest version:
http://www.w3.org/TR/xhtml-modularization Previous version:
http://www.w3.org/TR/2001/PR-xhtml-modularization-20010222 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)
Copyright ©2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
Abstract
This Recommendation specifies an abstract modularization of XHTML and an implementation of the abstraction using XML Document Type Definitions (DTDs). This modularization provides a means for subsetting and extending XHTML, a feature needed for extending XHTML’s reach onto emerging platforms.
Status of This Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used
Modularization of XHTML™
Modularization of XHTML
widespread deployment. This enhances the functionality and interoperability of the Web.
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.
Public discussion of HTML takes place on [email protected] (archive). To subscribe send an email to [email protected] with the word subscribe in the subject line.
Please report errors in this document to [email protected] (archive). The list of known errors in this specification is available at
http://www.w3.org/2001/04/REC-xhtml-modularization-20010410-errata.
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.
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.
Quick Table of Contents
. . . . . . . . . . . . . . . . . .
. 7
1. Introduction
. . . . . . . . . . . . . . .
. 11
2. Terms and Definitions
. . . . . . . . . . . . . . .
. 15
3. Conformance Definition
. . . . . . . . . . . . . .
. 21
4. Defining Abstract Modules
. . . . . . . . . . . . . .
. 29
5. XHTML Abstract Modules
. . . . . . . . . . . . . .
. 51
A. Building Schema Modules
. . . . . . .
. 53
B. Developing Schema with defined and extended modules
. . . . . . . . . .
. 55
C. XHTML Schema Module Implementations
. . . . . . . . . . . . . . .
. 57
D. Building DTD Modules
. . . . . . .
. 65
E. Developing DTDs with defined and extended modules
. . . . . . . . . . .
. 79
F. XHTML DTD Module Implementations
. . . . . . . . . . . . . . . . . .
. 169
G. References
. . . . . . . . . . . . . . . . .
. 173
H. Design Goals
. . . . . . . . . . . . . . . .
. 177
J. Acknowledgements
Full Table of Contents
. . . . . . . . . . . . . . . . . .
. 7
1. Introduction
. . . . . . . . . . . . . . .
. 7
1.1. What is XHTML?
. . . . . . . . . . .
. 7
1.2. What is XHTML Modularization?
. . . . . . . . . . . . .
. 7
1.3. Why Modularize XHTML?
. . . . . . . . . . . . .
. 8
1.3.1. Abstract modules
. . . . . . . . . . . .
. 8
1.3.2. Module implementations
Modularization of XHTML Quick Table of Contents
. . . . . . . . . . . .
. 8
1.3.3. Hybrid document types
. . . . . . . . . . . . . . .
. 9
1.3.4. Validation
. . . . . . . . . . . . .
. 9
1.3.5. Formatting Model
. . . . . . . . . . . . . . .
. 11
2. Terms and Definitions
. . . . . . . . . . . . . . .
. 15
3. Conformance Definition
. . . . . .
. 15
3.1. XHTML Host Language Document Type Conformance
. . . . . .
. 15
3.2. XHTML Integration Set Document Type Conformance
. . . . . . . . . .
. 16
3.3. XHTML Family Module Conformance
. . . . . . . . .
. 16
3.4. XHTML Family Document Conformance
. . . . . . . . .
. 17
3.5. XHTML Family User Agent Conformance
. . . . . . . . . . . . . . . .
. 18
3.6. Naming Rules
. . . . . . . . . . . . .
. 19
3.7. XHTML Module Evolution
. . . . . . . . . . . . . .
. 21
4. Defining Abstract Modules
. . . . . . . . . . . . . .
. 21
4.1. Syntactic Conventions
. . . . . . . . . . . . . . . .
. 22
4.2. Content Types
. . . . . . . . . . . . . . .
. 22
4.3. Attribute Types
. . . . . . . . . .
. 26
4.4. An Example Abstract Module Definition
. . . . . . . . . . . .
. 26
4.4.1. XHTML Skiing Module
. . . . . . . . . . . . . .
. 29
5. XHTML Abstract Modules
. . . . . . . . . . . . . .
. 29
5.1. Attribute Collections
. . . . . . . . . . . . . . . .
. 30
5.2. Core Modules
. . . . . . . . . . . . .
. 30
5.2.1. Structure Module
. . . . . . . . . . . . . . .
. 31
5.2.2. Text Module
. . . . . . . . . . . . .
. 32
5.2.3. Hypertext Module
. . . . . . . . . . . . . . .
. 32
5.2.4. List Module
. . . . . . . . . . . . . . . .
. 33
5.3. Applet Module
. . . . . . . . . . . . .
. 33
5.4. Text Extension Modules
. . . . . . . . . . . . .
. 34
5.4.1. Presentation Module
. . . . . . . . . . . . . . .
. 34
5.4.2. Edit Module
. . . . . . . . . . .
. 35
5.4.3. Bi-directional Text Module
. . . . . . . . . . . . . . .
. 35
5.5. Forms Modules
. . . . . . . . . . . . .
. 35
5.5.1. Basic Forms Module
. . . . . . . . . . . . . .
. 36
5.5.2. Forms Module
. . . . . . . . . . . . . . . .
. 38
5.6. Table Modules
. . . . . . . . . . . .
. 38
5.6.1. Basic Tables Module
. . . . . . . . . . . . . .
. 38
5.6.2. Tables Module
. . . . . . . . . . . . . . . .
. 40
5.7. Image Module
. . . . . . . . . . . .
. 40
5.8. Client-side Image Map Module
. . . . . . . . . . .
. 41
5.9. Server-side Image Map Module
. . . . . . . . . . . . . . .
. 42
5.10. Object Module
. . . . . . . . . . . . . . .
. 42
5.11. Frames Module
Full Table of Contents Modularization of XHTML
. . . . . . . . . . . . .
. 44
5.14. Intrinsic Events Module
. . . . . . . . . . . . .
. 44
5.15. Metainformation Module
. . . . . . . . . . . . . . .
. 45
5.16. Scripting Module
. . . . . . . . . . . . . .
. 45
5.17. Style Sheet Module
. . . . . . . . . . . . .
. 46
5.18. Style Attribute Module
. . . . . . . . . . . . . . . .
. 46
5.19. Link Module
. . . . . . . . . . . . . . . .
. 46
5.20. Base Module
. . . . . . . . . . . .
. 47
5.21. Name Identification Module
. . . . . . . . . . . . . . .
. 47
5.22. Legacy Module
. . . . . . . . . . . . . .
. 51
A. Building Schema Modules
. . . . . . .
. 53
B. Developing Schema with defined and extended modules
. . . . . . . . . .
. 55
C. XHTML Schema Module Implementations
. . . . . . . . . . . . . . .
. 57
D. Building DTD Modules
. . . . . . . . . . . . .
. 57
D.1. Parameter Entity Naming
. . . . . . . . . .
. 58
D.2. Defining the Namespace of a Module
. . . . . . . . . .
. 58
D.2.1. Qualified Names sub-module
. . . . . . . . . . .
. 60
D.2.2. Declaration sub-module(s)
. . . . . . . .
. 62
D.2.3. Using the module as a stand-alone DTD
. . . . . . . . . . .
. 64
D.2.4. Namespace Idiosyncrasies
. . . . . . .
. 65
E. Developing DTDs with defined and extended modules
. . . . . . . . . . . .
. 66
E.1. Defining additional attributes
. . . . . . . . . . . .
. 66
E.2. Defining additional elements
. . . . . .
. 66
E.3. Defining the content model for a collection of modules
. . . . . .
. 67
E.3.1. Integrating a stand-alone module into XHTML
. . . .
. 67
E.3.2. Mixing a new module throughout the modules in XHTML
. . . . . . . . . . . . . .
. 68
E.4. Creating a new DTD
. . . . . . . . . . . .
. 68
E.4.1. Creating a simple DTD
. . . . . . . .
. 70
E.4.2. Creating a DTD by extending XHTML
. . .
. 71
E.4.3. Creating a DTD by removing and replacing XHTML modules
. . . . . . . . . . . . .
. 71
E.4.4. Creating a new DTD
. . . . . . . . . . . . . . .
. 77
E.5. Using the new DTD
. . . . . . . . . . .
. 79
F. XHTML DTD Module Implementations
. . . . . . . . . . . . .
. 79
F.1. XHTML Character Entities
. . . . . . . . .
. 79
F.1.1. XHTML Latin 1 Character Entities
. . . . . . . . . . .
. 80
F.1.2. XHTML Special Characters
. . . .
. 82
F.1.3. XHTML Mathematical, Greek, and Symbolic Characters
. . . . . . . . . . . .
. 85
F.2. XHTML Modular Framework
. . . . . . . . . . .
. 87
F.2.1. XHTML Base Architecture
. . . . . . . . . . . . .
. 88
F.2.2. XHTML Notations
. . . . . . . . . . . . .
. 90
F.2.3. XHTML Datatypes
. . . . . . . .
. 91
F.2.4. XHTML Common Attribute Definitions
. . . . . . . . . . .
. 93
F.2.5. XHTML Qualified Names
. . . . . . . . . . .
. 98
F.2.6. XHTML Character Entities
Modularization of XHTML Full Table of Contents
. . . . . . . . . . .
. 98
F.3. XHTML Module Implementations
. . . . . . . . . . . .
. 98
F.3.1. XHTML Core Modules
. . . . . . . . . . . . . . . .
. 105
F.3.2. Applet
. . . . . . . . . . . . . .
. 106
F.3.3. Text Modules
. . . . . . . . . . . . . . . .
. 109
F.3.4. Forms
. . . . . . . . . . . . . . . .
. 118
F.3.5. Tables
. . . . . . . . . . . . . . . .
. 127
F.3.6. Image
. . . . . . . . . . . .
. 128
F.3.7. Client-side Image Map
. . . . . . . . . . . .
. 130
F.3.8. Server-side Image Map
. . . . . . . . . . . . . . . .
. 130
F.3.9. Object
. . . . . . . . . . . . . . .
. 131
F.3.10. Frames
. . . . . . . . . . . . . . . .
. 133
F.3.11. Target
. . . . . . . . . . . . . . . .
. 134
F.3.12. Iframe
. . . . . . . . . . . . . .
. 135
F.3.13. Intrinsic Events
. . . . . . . . . . . . .
. 137
F.3.14. Metainformation
. . . . . . . . . . . . . . .
. 138
F.3.15. Scripting
. . . . . . . . . . . . . .
. 139
F.3.16. Style Sheet
. . . . . . . . . . . . . .
. 140
F.3.17. Style Attribute
. . . . . . . . . . . . . . . .
. 141
F.3.18. Link
. . . . . . . . . . . . . . . .
. 142
F.3.19. Base
. . . . . . . . . . . . .
. 143
F.3.20. Name Identification
. . . . . . . . . . . . . . . .
. 145
F.3.21. Legacy
. . . . . . . . . . . .
. 151
F.4. XHTML DTD Support Modules
. . . . . . . . . . . . . .
. 151
F.4.1. Block Phrasal
. . . . . . . . . . . . .
. 154
F.4.2. Block Presentational
. . . . . . . . . . . . . .
. 155
F.4.3. Block Structural
. . . . . . . . . . . . . .
. 156
F.4.4. Inline Phrasal
. . . . . . . . . . . . .
. 160
F.4.5. Inline Presentational
. . . . . . . . . . . . . .
. 162
F.4.6. Inline Structural
. . . . . . . . . . . . . . . .
. 163
F.4.7. Param
. . . . . . . . . . . .
. 164
F.4.8. Legacy Redeclarations
. . . . . . . . . . . . . . . . . .
. 169
G. References
. . . . . . . . . . . . . .
. 169
G.1. Normative References
. . . . . . . . . . . . . .
. 170
G.2. Informative References
. . . . . . . . . . . . . . . . .
. 173
H. Design Goals
. . . . . . . . . . . . . . . .
. 173
H.1. Requirements
. . . . . . . . . . . . . . .
. 173
H.1.1. Granularity
. . . . . . . . . . . . . .
. 173
H.1.2. Composibility
. . . . . . . . . . . . . . .
. 174
H.1.3. Ease of Use
. . . . . . . . . . . . . .
. 174
H.1.4. Compatibility
. . . . . . . . . . . . . .
. 174
H.1.5. Conformance
Full Table of Contents Modularization of XHTML
Modularization of XHTML 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] [p.170]
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
1. Introduction Modularization of XHTML
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] [p.170] . Another implementation mechanism is XML Schema [XMLSCHEMA] [p.170] .
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.
Modularization of XHTML 1.3.1. Abstract modules
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.
1.3.4. Validation Modularization of XHTML
Modularization of XHTML 1.3.5. Formatting Model
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] [p.170] 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] [p.169]
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
2. Terms and Definitions Modularization of XHTML
entity reference
a mnemonic string used as a reference to the content of a declared entity (eg., "&" for
"&", "<" for "<", "©" for "©".) 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.
Modularization of XHTML 2. Terms and Definitions
tag
descriptive markup delimiting the start and end (including its generic identifier and any attributes) of an element.
2. Terms and Definitions Modularization of XHTML
Modularization of XHTML 2. Terms and Definitions
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] [p.170] , 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] [p.169] .
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, but XML Schema will be available soon.
The rest of this section refers to "DTDs" although other implementations are possible.
2. The DTD which defines the document type must have a unique identifier as defined in Naming Rules [p.18] that uses the string "XHTML" in its first token of the public text description.
3. The DTD 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 DTD which defines the document type may define additional elements and attributes.
However, these must be in their own XML namespace [XMLNAMES] [p.170] .
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
3. Conformance Definition Modularization of XHTML
1. The document type must be defined using one of the implementation methods defined by the W3C. Currently this is limited to XML DTDs, but XML Schema will be available soon.
The rest of this section refers to "DTDs" although other implementations are possible.
2. The DTD which defines the document type must have a unique identifier as defined in Naming Rules [p.18] that uses the string "XHTML" NOT in its first token of the public text description.
3. The DTD 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 DTD which defines the document type may define additional elements and attributes.
However, these must be in their own XML namespace [XMLNAMES] [p.170] .
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, but XML Schema will be available soon.
The rest of this section refers to "DTDs" although other implementations are possible.
2. The DTD which defines the module must have a unique identifier as defined in Naming Rules [p.18] .
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] [p.170] . 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.
Modularization of XHTML 3.3. XHTML Family Module Conformance
