xhtml basic: modularization in action

March, 2001.
By Molly E. Holzschlag. (Link to original article.)

HTML is not only officially dead, it's decomposing. That's really, truly the term the W3C uses to describe the concept of XHTML Modularization, which became a Candidate Recommendation as of October 20, 2000.

Maybe you've gotten used to the idea of XHTML 1.0. You may even write your documents using one of its three DTDs. Or maybe you're still using HTML and not paying much attention to W3C recommendations. After all, it's what works that matters, right?

While there's no doubt that one of a site designer's or developer's primary goals is to provide positive user experiences on the Web sites they design, there's also no doubt that the wireless age is upon us. Whether you've developed for wireless yet or not, increasingly industry pundits are saying that access to Web content via wireless and alternative devices will be more common than with PCs in a year or two.

So the primary challenge is how to write documents that work on a range of devices. Doing that is no simple task. It's hard enough to get our designs working successfully on today's myriad of browsers! XHTML modularization is the first step toward giving us the flexibility—and extensibility—we need to author documents for multiple devices.

By the time you read this, the status of XHTML Modularization will be at least in the Proposed Recommendation phase, if not the W3C recommended markup for both Web and alternative devices. By far, the best example of modularization to come out of the W3C is XHTML Basic, which uses modules specifically to create a language geared for wireless design.

Why xhtml?

XHTML 1.0, as a reformulation of HTML as an XML application, was the first to move away from the limitations of HTML toward the extensibility offered by XML. But XHTML 1.0 is limited in that it allows only three document type definitions (DTDs), each modeled after those found in HTML 4.0: Strict, Transitional, and Frameset. While XHTML 1.0 is well structured and well formed, you can't tap into some of the most powerful aspects of XML and related technologies. You can't write your own DTDs in XHTML 1.0. You can't use schemas. So extensibility really doesn't exist yet in the XHTML game, and XHTML 1.0 remains geared toward Web browsers.

XHTML 1.0 must be viewed as a means of allowing HTML authors—many of whom bootstrapped their way into the field—to painlessly gain entrance to the world of XML. Combining the familiar vocabulary of HTML with the strong syntactical influence of XML, XHTML 1.0 provides authors with a means of working with XML that makes perfect sense. Move to another XML application such as SMIL, SVG, or WML, and authoring those applications becomes much less daunting. An author can immediately see how XML, as a metalanguage for creating applications, can influence a wide range of languages. Learn one, and another becomes accessible. This relationship is the most compelling argument that XHTML 1.0 is not only reasonable, but necessary.

Why modularization?

With XHTML 1.0 comes organization. So why decompose that organization? It seems a bit bizarre at first glance to take Web markup, shore it up, then knock it down. But there's a method to the madness, and anyone interested in developing for multiple devices will come to appreciate this method.

Decomposing XHTML simply means that many familiar parts of XHTML 1.0 (and therefore HTML 4.0) are broken into separate modules. Programmers should be quite comfortable with the modularization concept. When coding Perl, for example, a programmer can use a module as a quick way to add an entire chunk of necessary goods. Instead of lines and lines of code, he or she adds just one line calling the module.

But for the client-side developer, the module concept might be a little harder to grasp. Here's an analogy I've found useful in describing it: To reduce the number of bruises on my body from hauling 15 pounds of computer equipment around on cramped airplanes, I bought a Sony Vaio. The beauty of this computer is that I can have all the extended capabilities of a CD-ROM, DVD, floppy drive—whatever my heart desires—by simply adding that component. But leave 'em all off, and I've still got a completely functional computer. Begin with a core, then add what you need. That's totally modular.

XHTML Modularization is basically the same thing. It includes a list of defined modules that express specific aspects of functionality. Then, these modules can be implemented using a DTD, which can, in a sense, be seen as the core. You can combine one, or two, or five, or more. You can even write your own additions, provided that you follow the recommended DTD and driver syntax. XML schemas are also expected to be implemented into this model, which means there's more than one way to approach a given challenge. Hence, if you want to write documents for a PDA, you can choose only those modules that let you do that. Extend that to a Web page, and you may want to add some extra modules to support your needs. In turn, these DTDs create XHTML subsets. Subsets can be shared by many (as is the case with XHTML Basic, which I'll discuss shortly), or completely customized for a given application.

If you're following along with this concept, you should begin to see the method to the madness, that herein lies the "X" in XHTML. Finally, extensibility has arrived via the power an author has over DTDs and the potential addition of XML schemas.

The proposed modules

No doubt you're getting curious as to what types of modules exist. At this writing, there are 21 modules with a few subcategories within them. These modules group related, often-used elements into discrete chunks. Some examples of the available modules include a structure module (with elements including head and body), a text module, image module, tables module, forms module, and so on.

So, you, the author, would take only the modules you require, and glue them together with a DTD or schema. The result is a streamlined, customized language that suits your specific needs—with no additional overhead.

XHTML basic: a living example of modularization

Right now, there really aren't too many examples of modularization in action. One very clean example is XHTML Basic, which became a W3C Candidate Recommendation in November 2000. XHTML Basic was created specifically for use in mobile and alternative devices such as smart phones, PDAs, pagers, automotive navigation systems, and computerized vending machines. These devices require streamlined markup because they don't have a lot of RAM or processing speed. Therefore, there's no room for a complex browser to interpret detailed code. Because of these limitations, XHTML is just that—basic!

XHTML Basic is meant to include only those methods in HTML and XHTML that are appropriate for these kinds of appliances. Given these restrictions, many elements and methodologies used in standard Web design are left out of XHTML Basic to let it deliver consistent information to special appliances.

Only some HTML and XHTML features can be used safely among all such appliance types without causing rendering problems. These include the use of text and basic text formatting, such as standard headings, paragraphs, and lists.

A critical feature for all hypermedia is, of course, the link. Basic forms are important for managing input and basic tables—in this case not for design or layout, but for their original intent: tabular data formatting. Images can be used in many instances, although they should be kept very small. Meta information can also be included, and is helpful for document identification, character set encoding, and search engine keywords.

XHTML Basic draws from these foundational methods. In some ways, XHTML Basic is much like early HTML. Simple, clean, logical.

What's supported and why

There are many items that can be included in XHTML Basic, and some that can't. Sometimes a technology is included, but only in part. The following technologies and modules are allowed in XHTML Basic:

Text.

Standard text is supported in XHTML Basic. Formatting including paragraphs, headers, breaks, and lists is also supported. It supports emphasis, but not italics.

Forms.

Very basic forms are allowed. These forms must comply with the Basic Forms Module. This module supports form elements common to HTML 3.2: form, input, select, option, and textarea.

Tables.

Tables from the Basic Tables Module are supported, including the following elements: caption, table, td, th, and tr.

Style Sheets.

External style sheets are supported via the link attribute. Elements including div, span, and class are also supported to allow the use of style. It's recommended that developers ensure graceful degradation for user interfaces that don't support style.

Images.

Images are supported using the img element, but use images very sparingly, and then only when they're extremely small in size.

So, with XHTML Basic, I could have body markup that's limited to paragraph markup like Example 1(a); paragraphs, headers, and lists as in Example 1(b); or a more complex sample using a basic table as in Example 1(c)).

Figure 1. Markup examples.

(a)
<p>Welcome to Molly's Wireless Web</p>

(b)
<h2>Welcome to Molly's Wireless Web</h2>
<p>Here you will find:</p>
<ul>
<li>Book Updates</li>
<li>Speaking Engagements</li>
<li>Contact Information</li>
</ul>

(b)
<p>Select one:</p>
<table border="1" cellspacing="0" cellpadding="2">
<tr>
<td><a href="updates.html">Book Updates</a></td>
<td><a href="speaking.html">Speaking Engagements</a></td>
<td><a href="contact.html">Contact Information</a></td>
</tr>
</table>

For my forms page, I could have a complete (but simple) form, and I could also use an external style sheet to apply style as I saw fit.

What's not supported and why

So what's been left out of XHTML basic? Lots! The limitations of alternative appliances make authoring for them quite restricted. Here's what you can't use in XHTML Basic:

Scripting.

The script and nonscript elements aren't supported. Scripts demand processing power, which many of the smaller, alternative devices simply don't have.

Frames.

Frames are based on the interfaces provided by a Web browser. Because the user agents in alternative devices are very limited and very small, frames don't make sense. As such, they're completely unsupported in XHTML Basic.

Objects.

The object element, used for things such as Java applets or Flash files, is prohibited. Once again, the simplicity of alternative devices doesn't allow for this kind of advanced functionality.

Imagemaps.

Because mapping requires input from a pointing device, and only a few alternative devices use pointers (for example, PDAs do, but pagers don't), imagemaps have been left out of XHTML Basic.

So, any inline script using the script element won't be allowed. Conceivably, I could use [CDATA] or the link attribute to link to an external script. However, scripting for alternative devices currently has limited usage, if it's useful at all. You'll also never see framesets in XHTML Basic, because the user agents don't have the power to support them.

The same is true of objects. Imagine trying to deliver a Flash file to a pager? Hardly! And, while small images are supported, imagemapping features aren't. Recall that original mapping was a server-side process, and later it was browser-based. Most user agents for small devices need to be lean, so there simply isn't the support. What's more, the point-and-click options available on a computer aren't available on most alternative devices.

If all this feels limited, it is! But these limitations empower you to deliver content to alternative devices. XHTML Basic doesn't exist for standard browser design. Rather, it's pared down, especially because alternative devices are, as a group, limited.

With an understanding of the fundamental concepts found in XHTML Basic, it becomes very easy to grasp how XHTML Basic uses XHTML modules. Several of these modules and associated elements are demonstrated in Table 1.

Table 1. Modules found in XHTML Basic.

Module	Elements Included
Structure	body, head, html, title
Text	abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var
Hypertext	a
List	dl, dt, dd, ol, ul, li
Basic Forms	form, input, label, select, option, textarea
Basic Tables	caption, table, td, tr, th
Image	img
Meta Information	meta
Link	link
Base	base

As you can see, modularization provides the building blocks for any XHTML Modularization subset. There are, as mentioned, other modules available for use, but only these modules are allowed in XHTML Basic.

XHTML basic document structure

An XHTML Basic document follows rules familiar to XHTML (and XML) authors. Documents must conform, validate, and contain specific syntax to enable this conformity and validation.

An XHTML Basic document must comply with the following guidelines:

• The document validates to the XHTML Basic> DTD.
• The document must contain a DOCTYPE definition denoting the proper DTD.
• The document's root element (as in XHTML itself) is html.
• The root element contains the default namespace for XHTML, further defining it as an XHTML-based document.

Conformance is an absolute in XHTML, and therefore, in XHTML Basic. As a result, XHTML Basic documents must validate against the named Basic DTD.

To establish the document as an XHTML Basic document, and to allow for validation, the DOCTYPE definition must be included. The root element is html because HTML is the vocabulary in use within the XHTML Basic markup.

Listing 1 shows an XHTML basic shell document with all the structure elements in place.

Making modularization work

While the uses of modularization will become much more diverse in the future, XHTML Basic is a perfect example of how to make modularization work today. By adding content to the shell I've created in Listing 1, you can create documents that are accessible by Web browsers and existing mobile devices such as cell phones and Palm handhelds. The reason you can do this is that the vocabulary is defined by HTML. But the syntactical rules evolve from XML, which in turn has given us XHTML. And that, in turn, has inspired modularization, taking us to an entirely new level of extensibility.