Inline and mixed-up markup Sometimes you may want to mix the HTML vocabulary with your own vocabulary at a very low level. A number of XML DTDs include the ubiquitous b and i element types for bold and italic; more use of HTML vocabulary types may make sense in your own markup. While this does not produce documents intended for a Web browser necessarily (unless you produce style sheets that make your XML readily presentable), it can make it easier to create document types without reinventing the wheel entirely. You can use HTML element names in your own XML without creating any (official) conflict with XHTML, provided that you don't use an HTML or XHTML namespace to identify your elements.

While your document structures may look like familiar XHTML to you, applications identify the information as belonging to your vocabulary rather than the XHTML vocabulary and rely on style sheets that you create for formatting or processing. There are some limits to this – as previously noted, images and scripts are especially difficult to process without using the functionality that browsers support for HTML. Still, if you only need to include a small fragment of familiar markup, this may be an appropriate route. If you want to stick to identifying XHTML as XHTML, you can – although you probably need to use namespace prefixes (and the default namespace, no prefix) to distinguish between your own vocabulary and the XHTML vocabulary. While it might seem obvious to you (or to document authors), it isn't so obvious to the programs processing your documents.

Is Formal XHTML Module Inclusion Worth the Trouble? The W3C has put forth a number of specifications that offer different approaches to mixing XML and XHTML, and the browser vendors (as previously noted) have focused on only one of those approaches – using namespaces to separate XML from HTML vocabulary. This approach doesn't require any DOCTYPE magic, nor do you have to create and manipulate parameterized XHTML DTDs. At the same time, however, you definitely lose something by skipping out on the DTD creation process described in the last article.

Caution As of this writing, none of the available browsers actually support the XHTML namespace (http://www.w3.org/1999/xhtml) as an identifier for HTML vocabularies. Using the namespace they do support (http://www.w3.org/TR/REC-html40) means that your documents don't conform to even the namespace end of XHTML, despite conforming otherwise. While it may be useful as a stopgap measure, be prepared for a massive search and replace when (and if) XHTML becomes the standard. XML 1.0 made a deliberate point of not requiring a DTD or even a DOCTYPE declaration for documents – although this lack of a DTD bars these documents from being used with a certain class of parsers, called validating parsers. Most browsers use non-validating parsers for processing XML and HTML. (Microsoft's built-in parser can be told to validate, but it doesn't normally validate when loading documents for display.) As a result, these tools don't check documents for conformance to an XHTML DTD. They also don't check the modules you create in addition to the XHTML DTD.

However, many other kinds of processors may check your documents against the DTD your documents specify, and they may reject documents that don't specify a DTD for such examination. If your documents have to deal with such parsers – which is likely if you exchange business information within your documents – the extra work of building XHTML DTD modules is worth the cost. (You need to create a DTD for your extensions anyway.) The modular and parameterized approach taken by XHTML 1.1 can help you manage and eventually extend the vocabulary and structures you create. Even if you don't know in advance that your documents will be subject to such inspection, you may find it useful to build an XHTML DTD module that provides a formal description of what you're doing. To a certain extent, it's a documentation process that codifies the work you do, while making it easier to share with others. This module also provides insurance against a future in which your documents may have to be fed into validating XML parsers, avoiding a major crunch. By creating constraints early, you can avoid producing a monstrous number of variations on your structures and make them more manageable. Having a DTD enables you to use a wider set of tools, as valid documents that conform to a specified DTD can be parsed by both validating and non-validating parsers and used in the applications built on those parsers.

While it may not be necessary in every case to build a formal description of what your extensions to XHTML are and how they integrate with the XHTML vocabulary, you definitely should consider the process as your documents move from prototypes and experiments to full-scale production. It's more than insurance against a changing future – it's an opportunity to learn about how you structure information and how to make necessary corrections early.