Mix and Match Markup: XHTML Modularization

May 2, 2001

Rick Jelliffe

XHTML Modularization makes it convenient to create specialized versions of XHTML: subsets with tailored content models and extensions in other namespaces. XHTML Modularization may be one of the most important new technologies of 2001. This article introduce the basics of XHTML modularization. The same approach can be used with many XML languages.


HTML is the major markup language used in the world today. However, it is source of wonder that the design of something so important should have been so out-of-control.

  • HTML started underdefined or, at least, with not much control,
  • but then proprietary extensions and incompatibility abounded,
  • so then attempts were made to rein in HTML by providing a DTD,
  • but it turned out that several DTDs were needed, (strict, loose and with frames) to manage the variants,
  • so the XML namespace mechanism was developed in part to allow more control (better labeling) of proprietary and standard extensions,
  • but the early assumption of some that namespace = DTD proved inappropriate for HTML, because generic processors were not interested in which HTML DTD was being used, they needed all HTML variants to belong to the same namespace.

The resulting situation, circa late 1999, was that the namespace mechanism and the three de facto standard W3C DTDs were not enough to meet the underlying requirement. Vendors and users needed to created supersets and subsets more conveniently.

The advent of W3C XML Schema seemed as if it might help by being namespace-aware and providing datatyping. But W3C XML Schema was clearly not being designed with XHTML's special needs as a primary requirement. Rather the Schema Requirements document was interested in generally reconstructing DTDs and supporting Java and SQL interchange. Convenience of use did not seem high on the agenda.

Furthermore, some of the key players in XHTML development had pragmatic and serious reservations about the applicability of W3C XML Schema. In particular, whether there would be much improvement over DTDs as far as XHTML's specific requirements were concerned. One of the leading voices of concern in this area was Sun's guru Murray Altheim, who has a web site, with the heading Long Live DTDs! (We're not exactly anti-schema, but we're sure pro-DTD.) If W3C XML Schema turns out to be good for XHTML modularization, it will not be because the early critics were wrong, but because they persisted and won through.

What Altheim and others recognized was that there was a missing layer required which would enable mix-and-match selection of components even within a namespace. So, for example, the mobile phone industry could define its own version of XHTML with the subset required (for example, to have no frames or tables) and with whatever other extensions are needed from other namespaces. From this realization came the XHTML Modularization project at W3C. A W3C Recommendation has been published at

("Modularization" is abbreviated M12N, in an obvious analogue to the way "internationalization" is abbreviated as i18n.)

XHTML Modularization is essentially a set of conventions for splitting up a large DTD into modules. Following these conventions, XHTML has been split into modules, which have been made available to the public.

Modularization works by providing a construct more largely-grained than the element and more finely-grained than the entire HTML namespace. The purpose of modularization is allow someone, perhaps not an expert in DTDs or Schemas, to restrict and extend their own version of HTML. Using modules means they won't miss something out by accident, as well as that there are placeholders for extensions and restrictions that are convenient and visible to others. So modularization does not actually alter the expressive power of DTDs or W3C XML Schema. Instead it provides an abstract model and practical conventions for how to organize a DTD or Schema.

As the abstract to the Recommendation Modularization of XHTML puts it,

This Recommendation specifies an abstract modularization of XHTML and an implementation of the abstraction using XML Document Type Definitions (DTDs). This modularization provide a means for subsetting and extending XHTML, a feature needed for extending XHTML's reach onto emerging platforms.

The Module Model

XHTML modularization has the following features.

The top-level document, which collects all the modules together. This document only references other DTDs, and does not contain any markup declarations in itself.
An entity which collects the various declarations relating to a distinct type of content. There are some core(required) modules which give the minimum declarations which a document type always needs in order to still be XHTML (or whatever language is being modularized), but most modules are optional.
Redefinable components
The various use of parameter entities in the HTML DTDs were analyzed to discover how they were being used. Various categories were introduced to handle the different uses: in the case of DTDs these are still implemented using parameter entities, but with a convention the parameter entity names have a suffix giving their category. In an W3C XML Schema implementation, many of the categories have more direct analogs. The categories include:
  • .content for general content models
  • .class for substitution groups
  • .mix for mixed content models
  • .attrib for attribute groups
You customize XHTML by redefining the declarations in those categories.

The abstract modules into which XHTML has been divided are:

  • Structures (core)
  • Text (core)
  • Hypertext (core)
  • List (core)
  • Applet
  • Text Extension
  • Forms
  • Table
  • Image
  • Client-side Image Map
  • Server-side Image Map
  • Object
  • Frames
  • Target
  • Iframe
  • Intrinsic Events
  • Metainformation
  • Ruby Annotations
  • Scripting
  • Style-sheet
  • Style Attribute
  • Link
  • Base
  • Name Identification

There are other modules for low-level housekeeping, and it is possible that some other modules, notably for Math ML will be used. So the modularization approach also will help make extensions of XHTML and HTML within the HTML namespace practical, which some may see as ironic: the purpose of XML Namespaces is to allow modularity, yet there are good reasons why, in the case of XHTML, the namespace should be allowed to grow. Document-type evolution does not always mean merely adding a new element in a new namespace. Even document types with a single namespace may need to be maintained and grow.

Modules using DTDs

Modularization gets more complex when you want to add your own elements or customize content models. But the most basic use of just creating an XHTML subset is quite simple.

There are several ways to use modularization with DTDs. The most common way is subtractively. You set some switches (parameter entities containing IGNORE or INCLUDE keywords for marked sections) to override the settings of a canned driver file such as To make a version of XHTML without applets and objects, you do something like the following:


xhtml-applet.module "IGNORE" > <!ENTITY % xhtml-object.module


<!ENTITY % xhtml11.mod

     PUBLIC "-//W3C//DTD XHTML 1.1//EN"

            "" >


The other way to use modularized DTDs is additively, where you explicitly create your own driver file, including various modules as you will. I include an example of the additive method for comparison with the XML Schemas example below. Here is an example for a minimal language which only contains the basic head-body structure, text, hypertext, lists, tables, images and image maps.


     PUBLIC "-//Rick Jelliffe//SGML XHTML Little HTML 1.0//EN"


<!ENTITY % XHTML.ns  "" >

<!-- required -->

<ENTITY % xhtml-framework.mod

     PUBLIC "-//W3C//ENTITIES XHTML 1.1 Modular Framework 1.0//EN"

            "xhtml11-framework-1.mod" >


<!ENTITY % xhtml-text.mod

     PUBLIC "-//W3C//ELEMENTS XHTML 1.1 Basic Text 1.0//EN"

            "xhtml11-text-1.mod" >


<!ENTITY % xhtml-hypertext.mod

     PUBLIC "-//W3C//ELEMENTS XHTML 1.1 Hypertext 1.0//EN"

            "xhtml11-hypertext-1.mod" >


<!ENTITY % xhtml-list.mod

     PUBLIC "-//W3C//ELEMENTS XHTML 1.1 Lists 1.0//EN"

            "xhtml11-list-1.mod" >


<!ENTITY % xhtml-struct.mod

     PUBLIC "-//W3C//ELEMENTS XHTML 1.1 Document Structure 1.0//EN"

            "xhtml11-struct-1.mod" >


<!-- optional -->

<!ENTITY % xhtml-table.mod

     PUBLIC "-//W3C//ELEMENTS XHTML 1.1 Tables 1.0//EN"

            "xhtml11-table-1.mod" >


<!ENTITY % xhtml-image.mod

     PUBLIC "-//W3C//ELEMENTS XHTML 1.1 Images 1.0//EN"

            "xhtml11-image-1.mod" >


<!ENTITY % xhtml-csismap.mod

     PUBLIC "-//W3C//ELEMENTS XHTML 1.1 Client-side Image Maps 1.0//EN"

            "xhtml11-csismap-1.mod" >


<!ENTITY % xhtml-ssismap.mod

     PUBLIC "-//W3C//ELEMENTS XHTML 1.1 Server-side Image Maps 1.0//EN"

            "xhtml11-ssismap-1.mod" >



Modules using XML Schemas

Daniel Austin of Mozquito Technologies AG has been working on a draft specification for implementing modularization using XML Schemas. A draft is now available, and public comments solicited, at (The approach is similar to that in will be similar to "An Approach to the Modularization of XHTML using XML Schemas". )

This approach is a little different than the DTD approach. In the simplest use of DTD, you start with a complete XHTML and weed out the modules you don't want with explicit IGNORE settings, while the XML Schemas approach is to only include modules you need. However, the important thing is that both methods allow the same result: you can select or reject the modules using a single statement.

What is most surprising, to me anyway, is that XML Schema is simpler and more straightforward to use than DTDs. XML Schema provides higher-level constructs which, though not as high-level as those of the M12N abstract model, are closer to the M12N model than DTDs.

So the mapping from XHTML M12N concepts to XML Schemas requires less glue than DTDs require. Support for XHTML M12N is an important, though late use-case for XML Schemas.

Rather than give details, here is a simple example of what a driver (hub document) might look like in XML Schemas. See the XHTML M12n in XML Schemas draft for more concrete details. Note that the modules are simply included, commented out, or deleted.

<schema xmlns=""

   version="-//Rick Jelliffe//SGML XHTML Little HTML 1.0//EN"




         <documentation>This is a simple example of XHTML Modularization.



    <-- core module -->

    <include  schemaLocation="xhtml-framework-1.xsd" /> 


     <-- optional modules -->

    <include  schemaLocation="xhtml-table-1.xsd" />

    <include  schemaLocation="xhtml-image-1.xsd" />

    <include  schemaLocation="xhtml-csismap-1.xsd" />

    <include  schemaLocation="xhtml-ssismap-1.xsd" />




The apparent simplicity hides the exhaustive analysis of HTML by the experts at the W3C HTML Working Group to partition HTML into modules. And some of the simplicity compared to the DTD version above is superficial. The DTD version above provides public identifiers as well as the system identifier, and the designers of the XHTML modularization could have chosen to incorporate the required modules into a single module for terseness.

The redefine element in XML Schemas was introduced specifically to support the XHTML M12n use-case. Features such as include, import, and redefine are syntactic sugar which do not increase the power of XML Schemas: you could do the same by editing the schema document by hand. Instead they make it convenient to use and reduce the amount of messy glue needed to impose some higher-level abstractions, such as modules, which group schema components.

W3C XML Schema is not perfect yet. In particular, XML Schema operates on the infoset (the parsed XML content) rather than the document as it is being parsed. So the issue of how to treat special character entity references is still open.

There is also an interesting bootstrapping issue. It would be desirable to have the documentation contain XHTML elements, but that might tax some Schema processors, especially in the early days. In general, it is unwise to use elements in a namespace inside a schema defining that namespace. So it is possible that XHTML schemas will be the only schemas that cannot use XHTML for documentation.


Evidence for the success of the XHTML Modularization concept may be found in the rapid development of the RDDL language, which is Jonathon Borden and Tim Bray's (with others) Resource Directory Description Language, a version of XHTML with a simple linking element added in another namespace to point to the various resources related to a namespace URI. It is exactly the kind of DTD that XHTML M12n is good at, though XML M12n was inspired by the needs of PDAs or small appliances.

The next question that arises is whether the modularization system would be useful for other large languages that we might wish to subset (did anyone say XML Schema?) The question is whether that kind of modularization allows the cake to be sliced in the most appropriate way. Additive modules could clearly be used to handle, for example, selecting or not selecting a key/keyref module, but if facets were modularized, an additive driver might be quite large, and there is no subtractive M12n approach tabled for XML Schemas. But still, the document would be simple to read and straightforward to create.

The final question is whether, if modularization in XML Schemas is useful, there should be first-class markup to support it? Presumably, the way to approach this would be to provide some first-class support so that there might be a <module> element which could be used by some schema-management tools directly, to provide markup rather than just conventions. A modularization system for XML Schemas should look at the modularization system in the RELAX language (which is based on Toru Takahashi's early designs for SGML.)