This section is normative.
Partitioning of the document model occurs at the abstract module level. This partitioning is implemented in the markup model by two primary methods: parameterization, the use of parameter entities as reusable strings, and modularization, the creation of DTD fragments called modules.
This specification classifies parameter entities into six categories and names them consistently using the following suffixes:
.modwhen they are used to represent a DTD module (a collection of element classes). In this specification, each module is an atomic unit and may be represented as a separate file entity.
.modulewhen they are used to control the inclusion of a DTD module by containing either of the conditional section keywords INCLUDE or IGNORE.
.contentwhen they are used to represent the content model of an element type.
.classwhen they are used to represent elements of the same class.
.mixwhen they are used to represent a collection of element types from different classes.
.attribwhen 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.0, the %block; parameter entity is defined to represent the heterogenous collection of element types that are block-level elements. In this specification, the corollary parameter entity is %Block.mix;.
DTD modules are often used to encompass the markup declarations of a specific semantic component or "feature", from higher-level document features like tables and forms, to lower-level components such as specific elements or element groups. Modules can even contain modules, creating a hierarchical structure mirroring the document model. Note that modules are not always implemented as separate file entities, and modular DTDs can be easily normalized into single file versions for more efficient distribution over the Web.
The relationship between document model components and how they are implemented in markup as modules, entities and files (i.e., the granularity of the parameterization or modularization, how the markup model is structured and stored as separate entities, etc.) is not necessarily direct, as design style and implementation issues properly play a part. Higher-level modules are sometimes delivered as individual file entities to facilitate portability and reusability. To promote interoperability, the XHTML DTD design considers each module as atomic, with the notion that implementations should support the semantics of an entire module without further subdivision.
While the notion of "plug and play" with DTD modules is very attractive, in practice this is not quite so simple. Complex document models often resort to extensive parameterization of abstract modules to facilitate understanding, markup reuse, extensibility, and maintenance. The resultant modules may have have many interdependencies, and may require a fair amount of "rewiring" when adding or removing a DTD module. In light of this, a compromise must be made between markup flexibility, complexity of the DTD, and ease of maintainability.
The XHTML DTD attempts to ameliorate this by localizing many of the more "global" parameter entities to several modules that are declared early in the DTD. These are labelled common modules, and include declarations for common names, attributes, parameter and character entities.
XHTML elements are classified into the following categories: