5. XML DTD Modules


This section is normative.

5.1. Implementing Document Model Modules in the DTD

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.

5.1.1. Parameterization

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

parameter entities use the suffix .mod when 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.
parameter entities use the suffix .module when they are used to control the inclusion of a DTD module by containing either of the conditional section keywords INCLUDE or IGNORE.
parameter entities use the suffix .content when they are used to represent the content model of an element type.
parameter entities use the suffix .class when they are used to represent elements of the same class.
parameter entities use the suffix .mix when they are used to represent a collection of element types from different classes.
parameter entities use the suffix .attrib when they are used to represent a group of tokens representing one or more complete attribute specifications within an ATTLIST declaration.

For example, in HTML 4.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;.

5.1.2. Modularization

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 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 sub-modules that are brought in via a "framework" module. These include declarations for common names, attributes, parameter and character entities.

XHTML elements are classified into the following categories:

structural element types
element types that create the overall structure of an XHTML document.
block element types
element types that should cause a line break.
inline element types
element types that are displayed inline to an existing block.
phrasal element types
element types that specify a domain-relevant connotation
presentational element types
element types that indicate a desire on the part of the author for a specific rendering effect.
special case (or "feature") element types
element types that provide XHTML with special features, such as linking, forms, etc.