Mixing XHTML into Your Applications
The advantage to dividing HTML into all these different modules is that you can pick and choose the pieces you want. If your documents use tables, include the Tables module. If your documents don’t use tables, then leave it out. You get only the functionality you actually need.
For example, let’s suppose you’re designing a DTD for a
catalog. Each item in the catalog is a catalog_entry element. Each catalog_entry contains a name, price, item_number, color, size, and various other common elements
you’re likely to find in catalogs. Furthermore, each catalog_entry contains a description of the item. The description contains formatted narrative
text. In other words, it looks something like this:
<catalog_entry>
<name>Aluminum Duck Drainer</name>
<price>34.99</price>
<item_number>54X8</item_number>
<color>silver</color>
<size>XL</size>
<description>
<p>
This sturdy <strong>silver</strong> colored
sink stopper dignifies the <em>finest
kitchens</em>. It makes a great gift for
</p>
<ul>
<li>Christmas</li>
<li>Birthdays</li>
<li>Mother's Day</li>
</ul>
<p>and all other occasions!</p>
</description>
</catalog_entry>It’s easy enough to write this markup. The tricky part is validating it. Rather than reinventing a complete DTD to describe all the formatting that’s needed in straightforward narrative descriptions, you can reuse XHTML. The XHTML 1.1 DTD makes heavy use of parameter entity references to define content specifications and attribute lists for the ...