Fragmenting XHTML is useful if you want to implement portions of XHTML, but many developers need to go the other direction and supplement XHTML's functionality. Fortunately, you can use the exact same set of tools the W3C used to create the XHTML modules to create your own modules. One of the editors of the XHTML drafts, Murray Altheim, has published some tools and templates that may help you get started. It isn't easy, but it's not exactly rocket science either. Of course, defining the markup alone doesn't transform user's Web browsers instantly – you still have to perform a lot of software development (or, at the very least, style sheet development) to make your shiny new vocabularies work.

Tip You really only need to read this article if you plan to build your own extensions to XHTML or you need to understand how new modules from various sources integrate with XHTML. If that isn't your goal right now, skip ahead and come back if you need this material.

Building Your Own Modules The first part you need to define is the content of your XHTML module. You may be starting from scratch, building your module on the XHTML DTD framework, or converting an existing XML DTD to an XHTML module. In any case, creating an XHTML module involves a good deal more work and tends to produce a much more verbose document description than creating an ordinary XML DTD. You must combine the basic tools described in Article 6 with the approach described in Article 15, and you should document your work in an abstract module that goes beyond simple DTD creation. While there is definitely extra work involved in creating a formal XHTML module that uses all the parameterization conventions created by the W3C, this approach should produce a more usable result.

Caution You can create modules that work without using the parameter entity and conditional sections approach. After all, modules are just DTDs, and parsers won't care about how many parameter entities or conditional sections you used to create the DTD. On the other hand, developers outside of your project may have a much harder time working with and integrating your vocabulary into their work. Even if you're just prototyping, starting out with and sticking to the XHTML approach makes the management of your modules much easier. For the most part, building an XHTML module means creating your own vocabulary and laying it out as a set of elements and attributes. It's basically the same as creating an XML vocabulary, with a few extra pieces. I don't cover the ins and outs of creating XML vocabularies here, as that task is well described in (and requires) lots of separate articles. Instead, I walk you through a very simple but plausible XHTML module for describing biographical information within XHTML documents.

Note Lots of articles describe how to create your own XML vocabularies. XML: A Primer (Simon St. Laurent, IDG Articles, 1999) describes XML and provides numerous examples, while XML Elements of Style (Simon St. Laurent, McGraw- Hill, 2000) goes into much more detail about the rules and traps of XML. The XML Bible (Elliotte Rusty Harold, IDG Articles, 1999) runs through a series of baseball-oriented examples in detail. David Megginson's Structuring XML Documents (Prentice-Hall, 1998) moves more into SGML, but provides detailed descriptions of various approaches to XML document structure.

Tip If you want to get a head start on your module creation and avoid some of the work described in the next few sections, take a look at archy and instance karma. Both are from Murray Altheim, one of the editors of XHTML 1.1. archy (available http://www.doctypes.org/archy/home.html) is a framework for building XHTML modules, while instance karma (available at http://www.doctypes.org/instkrma/home.html) is an XSLT style sheet that builds a shell DTD from a sample document. If you want to start by creating sample documents, this approach can save you a lot of time. The XHTML-Biography module you create in this article can include and be included in XHTML 1.1 documents, which means that the customization file is especially important. Most of the functionality provided by the module doesn't require extra processing beyond the capabilities of relatively simple cascading style sheets, so you can put the module to work in browsers easily. Non-browser application structures, such as filters that search for information on particular people, can treat the XHTML documents created with this module as XML and seek out the markup vocabulary you create to track down biographical information. In planning the module, you design for two different kinds of situations and try to accommodate both. The first case is a formal biography, a description within an HTML document that provides a complete biography of a person possibly presented in a different way than the rest of an HTML document. These formal biographies use the markup you create here for their basic structures, and a mixture of ordinary HTML and biographical markup for their contents. The second case enables developers to mark up biographical information within other XHTML documents without the trouble of a full biography. It might point to a formal biography, or it might help automated processors track down documents that contain information about a particular person. This approach is very useful for news sites because it lets them build search engines, for instance, to supplement this module with other modules describing companies and other organizations. To identify your elements, use this namespace:

http://www.simonstl.com/xhtml/xhtml-biography/ Within the DTD and abstract modules, use the prefix biog. (Using bio invites conflicts with biology and changing the prefix can break validation, as described later in this article.) Let's start by creating an abstract module that describes what you're doing here, and then move into the formalities of building a DTD using the XHTML conventions. You need to create elements for identifying biographies when they appear in documents, and these can act as containers for a more formal set of descriptions. Then you create a separate container for identifying people within ordinary XHTML content. Working inside of XHTML documents may require a much more flexible approach while still describing similar information. Neither of these elements needs many attributes beyond the Common core. You can use the id and class attributes if needed to identify particular biography information sets within a document. The biog:person element can have a more attribute pointing to a fuller set of information about the person, if appropriate. The content model for biog:biography is much stricter than that for biog:person, but to a sizable extent that is because you plan to have substantially more control over the content and presentation of biog:biography elements. The biog:person element type must demonstrate more flexibility in order to be useful; it should work in situations in which only partial information is available, as well as in a wider variety of sequences.

Apart from biog:name, all of these elements only contain text. Because names may appear in different orders in different cultures, biog:name has become extremely flexible (perhaps too flexible). You can specify more parts for all of these – the title can refer to the position and the organization or location to which it applies, and the birth and death dates can break down into year, month, and day. For now, let's use date as a placeholder for PCDATA to make its contents more explicit. (This has no effect on parsing.) It's also possible that these items should permit inline HTML elements as well, but let's opt not to do that for now. This should be all the abstract model you need, so let's move on to building the DTD module and making use of XHTML 1.1's set of naming conventions. Start by declaring the date data type:

 <!ENTITY % date.datatype  "#PCDATA">

You don't have any classes or mixes defined in this module, but you use classes defined in XHTML (Block and Inline) to define content models in your element declarations. First you define your elements as suggested in the XHTML specifications, creating a parameter entity that contains the element content model, and then you use that parameter entity in the element type declaration.