Simply put, modularization is the concept whereby markup definitions are divided up into subsets, where each individual subset focuses on specific functions or capabilities. Likewise, the markup definition modules that result from this exercise work like building blocks, in that certain modules must be present to provide a foundation for other modules that build on or extend their functionality. Understanding the relationship between include files, class files, or other data definitions in programming languages will help you in figuring out which kinds of relationships can exist among markup modules in XML.
Follow the examples and the various simple rules of thumb that I provide below to make the most of modularization in XML. By creating collections of reusable markup parts, you can simplify how you describe your XML documents and limit customization to only those modules where it’s absolutely necessary.
To date, one of the most convincing demonstrations of XML modularization is modular XHTML (aka XHTML 1.1). Basically, XHTML 1.1 takes the markup definitions defined for XHTML 1.0 and divvies them up into modules that create an immutable core of markup definitions into and around which other optional modules can come and go for a variety of purposes or applications. One of the goals that drove this modularization effort was a desire to define minimal markup sets suitable for use on cell phones and other handheld devices with limited display areas and capabilities. Table A sums up XHTML 1.1’s modules and briefly lists their structures and functions.
The XHTML recommendation, XHTML Basic, defines a minimal subset of modules that aims at mobile phones, handheld devices, and other devices with limited displays and computing capabilities. XHTML 1.1 is described fully in two W3C recommendations: Modularization of XHTML and XHTML 1.1 - Module-Based XHTML.
The real benefits of modularization include:
- It permits related sets of markup and functionality to be organized into logical and physical modules.
- It identifies core components that must be present and optional components that may or may not appear.
- It catalogs dependency relationships among modules so that any module that requires other modules to instantiate it is noted as such. (Note that DTD syntax is such that calling modules must precede called ones—the opposite of include files.)
- Individual modules may be customized as needed; this makes it easy to add or extend functionality where needed, while leaving other modules alone.
- XML applications can be constructed out of building blocks, including standard modules and custom modules, only as needed or wanted. This provides great flexibility and tight scoping of functionality.
Modularization in action
When using modularized XML, to invoke and use predefined modules like those associated with modularized XHTML, or to invoke and use publicly available or custom-built modules, the technique is quite simple. Basically, you must create an internal DTD section in your XML documents or make references to an external DTD, XML Schema, or equivalent in your XML documents where the XML modules you wish to use are invoked.
The syntax to invoke an XML module is simple, and can be expressed in this general form:
<!ENTITY % <module name>.mod
PUBLIC "-//W3C//ELEMENTS XHTML <module name> 1.0//EN"
Substitute the real module name for the <module name> item, and do the same with <mod-abbrev> for any applicable module abbreviation that may apply, and you’re finished. To use the text module from modular XHTML as an example, this generic format translates into the following:
<!ENTITY % xhtml-text.mod
PUBLIC "-//W3C//ELEMENTS XHTML Text 1.0//EN"
In this case, the module name and abbreviation were the same, but this isn't always true for the XML modules I’ve seen; that’s why they get separate placeholders in my generic description.
What to remember
Construction of complete XML module collections is demonstrated in the XHTML basic DTD available as part of that recommendation’s documentation online at the W3C. The important principles to remember when designing and building module XML documents are:
- Let the markup drive modularization. It’s essential to identify the basic core that’s common to all applications and require it as a minimal subset.
- Let functionality or application needs drive markup encapsulation for other modules.
- When building a modular DTD or XML Schema, invoke items in reverse dependency order. If you don’t get things right the first time, look to invocation order as the most likely source of your problems.