Developer

Build and customize modular XML to simplify your XML documents

Developers have been working with objects and modules for some time, but now XHTML 1.1 introduces this concept to the XML world. Learn more about this important advancement and how to put it to use in your XML documents.

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.

Modular XHTML
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.
Table A
Module name Description
Core modules  All four core modules needed for minimal XHTML 
Structure XHTML structure elements (body, head, etc.)
Text Basic text container elements
Hypertext Basic hyperlinking (a element)
List List-oriented elements
Applet Supports the deprecated applet element
Text extension modules Supports enhanced textual markup (relative font sizes, editing-related, and bi-directional text)
Forms modules  
Basic forms Minimal set of forms markup
Forms Complete set of forms markup
Table modules  
Basic tables Minimal set of table markup
Tables  Complete set of table markup
Other modules  
Image Provides basic image embedding
Client-side image map Handles client-side image maps
Server-side image map Handles server-side image map formats
Object Supports general inclusion of external objects
Frames Supports (X)HTML frames
Target Supports destination targets for selections
Iframe Supports use of inline frames
Intrinsic events Support intrinsic XHTML events (onblur, onfocus, onload, onunload, onchange)
Metainformation Supports meta element
Scripting Enable/disable support for executable scripts
Style sheet Enables declaration of internal style sheets
Style attribute Enables use of the style attribute
Link For defining links to external resources
Base Provides context for relative URLs
Name identification Supports the deprecated name attribute
Legacy Supports deprecated elements and attributes
XHTML abstract modules

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"
"xhtml-<mod-abbrev>-1.mod" >
%xhtml-text.mod;

 

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"
"xhtml-text-1.mod" >
%xhtml-text.mod;

 

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.

 

Editor's Picks