The theory behind fragmentation, presented in the previous article, sounds pretty good. Fragmentation appears to be a cure to the many ills of the Web, pointing the way forward to new XML vocabularies and new possibilities. The concrete implementation details of XHTML 1.1, however, look rather scary. Contained in three drafts with a total of about 180 pages, the XHTML 1.1 specs are a daunting collection of rules (and the application of those rules) that applies to the XHTML vocabulary. Fortunately, while the rules make use of XML's funkier tools, the way they actually work isn't very painful and developers may be able to avoid the frightening details.

Note The content of this article is based on the 5 January 2000 Last Call Working Drafts of the XHTML 1.1 specifications. Some content may change between the time of this writing and the final approval of the specifications by the W3C, so you should check to find out the current or final status of these issues.

XHTML as Framework Unlike its predecessors, XHTML 1.1 provides an architectural framework for syntax rather than a simple concrete implementation. XHTML 1.1's architecture for defining modules is effectively a layer on top of XML 1.0's rules for creating DTDs, and its own implementation of the XHTML vocabulary is a layer on top of that one. To simplify all of these layers and their interactions, XHTML 1.1 has these three separate documents defining it:

- Building XHTML Modules (http://www.w3.org/TR/xhtml-building) provides the formal framework on which the XHTML modules (and other modules) are built.

- Modularization of XHTML (http://www.w3.org/TR/xhtml-modularization) describes how you implement XHTML 1.1 using that framework.

- XHTML 1.1 - Module-based XHTML (http://www.w3.org/TR/xhtml11) describes how you create XHTML 1.1 documents using these modules.

In a sense, XHTML is two separate parts defined in three specs. The first part is the framework – how to create the modules (defined in Building XHTML Modules) and how to reassemble them as documents (defined in XHTML 1.1 - Module-based XHTML). The second part is the implementation that Modularization of XHTML – and to some extent XHTML 1.1 - Module-based XHTML – defines. This article walks through the framework on the way to the implementation explanation, breaking down each component of XHTML while staying within its general bounds. The framework combines a set of rules for creating modules and different kinds of descriptions of those modules, as well as a set of rules for integrating those modules to create a larger whole. The process of breaking XHTML into modules uses the former set of tools, while documents that use just XHTML rely on the latter.

Abstract Modules XHTML prescribes both formal and informal ways to describe modules. Abstract modules are documents intended purely for human consumption, helping readers avoid the tangle of parameter entity processing needed by the formal tools for describing modules. This level of description is useful both for documentation and planning, forcing developers to specify what their modules contain in a format that goes beyond the prickly formal tools of DTDs and XML Schemas. Abstract modules are not required for conformance to the XHTML 1.1 specifications, but their use can make creating and using XHTML 1.1 modules much easier.

Note Abstract modules are defined in Section 4 of Building XHTML Modules, available at http://www.w3.org/TR/xhtmlbuilding/abstraction.html#s_abstraction. Abstract modules are basically tables with some supporting textual content. The tables consist of lists of elements with columns for attributes and minimal content models. Because some elements may be defined with content sets, such sets may be described in ways that aren't explicitly included in the table. Content sets are typically used repeatedly in multiple elements, so this special treatment probably makes sense. No such provision is made for sets of attributes, however. (One exception: using Common as an identifier for a core set of attributes in the XHTML 1.1 DTDs.) Within those tables, XHTML uses a semiformal syntax that looks like an extended (and reduced) version of XML DTD syntax.

This describes the element type textElement, which uses the XHTML Common set of attribute declarations (defined at http://www.w3.org/TR/xhtmlmodularization/ xhtml_modules.html#s_basicattributes) and contains only text. Most modules undoubtedly are more complex than this one, but sometimes only a single element is needed to add functionality. Before you move on to a more complicated example, you should note some of the pieces that are missing from the abstract module descriptions created in accordance with the Building XHTML Modules draft. No information is provided about namespaces. This is reasonable when working strictly within XHTML where all the parts share a common namespace. However, omitting namespaces is probably not such a good idea when creating extensions to XHTML (as you do in the next article). While the prefixes may appear in the element names, the URIs they map to need to be documented somewhere. Also missing is an explanation of how you should integrate this module with other modules. It isn't clear how to use this module and its components appropriately within an XHTML framework. This kind of documentation should form an important supplement to the abstract module framework described in the specification itself.

Keeping those warnings in mind, take a look at one of the abstract modules defined in Modularization of XHTML to see how these tools are used (see sidebar). The Forms Module is fairly complex, but familiar to most HTML developers, and it contains a variety of content models. While its actual content may change on the path to becoming a W3C recommendation, it has some excellent examples of the abstract module syntax in action and shows how additional textual content can fill in the gaps of an abstract module. Let's start with the module in the sidebar (from Section 4.5.2), and then explore its pieces. 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 Basic Text Module. The Forms Module is a superset of the Basic Fjorms Module. These modules may not be used together in a single document type.