- Dissecting an XML Document Type Definition
- Using Document Type Definition Notation and Syntax
- Understanding Literals
- Declaring a NOTATION
- Creating ATTLIST Declarations
- Using Special XML Datatype Constructions
- Understanding the Difference Between Well-Formed and Valid XML
- Learning How to Use External DTDs and DTD Fragments
- Altering an XML DTD
- Getting Down to Cases
Altering an XML DTD
Several mechanisms are built into the XML DTD to allow you to alter an existing DTD. The first of these, conditional markup, has to be built into the DTD when it's created but, after that, you can change how it behaves on-the-fly by overriding the value of one or more parameter entities. The other mechanisms described in the following sections, adding new attributes or elements, require less planning but their effects are invisible to other users of the DTD. The appropriate mechanism in each case is a design decision.
Many people can't see the use for conditional markup. However, this facility gives the DTD designer the ability to create "debugging" or alternative versions of the DTD that reside in the file itself, where they can't be lost and where you can encourage people who change anything to make sure to handle the conditional parts as well.
Conditional markup uses the familiar parameter entity mechanism to declare particular items as having the value IGNORE or INCLUDE. They look quite a bit like a CDATA section except that the contents must be markup surrounded by the special conditional begin and end sequences:
<!DOCTYPE book PUBLIC ... [ <!ENTITY % debug 'INCLUDE' > <!ENTITY % release 'IGNORE' > ]> <!ENTITY % debug 'IGNORE' > <!ENTITY % release 'INCLUDE' > <![%debug;[ <!ELEMENT book (comments*, front, body, back?)> ]]> <![%release;[ <!ELEMENT book (front, body, back?)> ]]>
To swap back and forth between versions that allow comments to be prepended to the book and those that don't, just override the debug and release entity values somewhere in the internal DTD subset. Note that the strings DEBUG and IGNORE are XML keywords and have to be in uppercase as shown; however, you can use any appropriate name for the parameters. Also note that DEBUG is just a value. You can use this mechanism to construct arbitrarily complex DTD variants by judicious choice of sections to be selectively included or skipped, and by creating parameter entities that select or ignore them. Few DTD designers on small projects are ever likely to have to use this tool as it was designed in SGML for environments with scores of coders working over months and years. When your DTD is thousands of lines long, you don't want to fool around with ad hoc debugging changes. The fact that you can use the mechanism in other ways is a bonus.
Using New Attributes
An attribute can be added to an element at any time because attribute lists are concatenated with the first declaration of any particular attribute name taking precedence over any following declaration. If there are no duplicates, the attribute is added to the list of existing attributes, or creates a new one if attributes had not been previously declared. Chapter 4 covers this topic in detail.
You just add an ATTLIST declaration to the internal DTD subset or equivalently an external DTD file which reads in your new attribute declaration before reading in the DTD proper. Here we add a required field to the alt attribute for an image to encourage people to use it as the WAI recommends:
<DOCTYPE book [ <!ATTLIST image alt CDATA #REQUIRED> ]>
Using New Elements
Elements are a little harder, although easily done. You have to find a place for them in the existing DTD and go through a sometimes lengthy process to fit them in, but it's largely a piece of cake. Chapter 4 goes into great detail on this subject. This oversimplified example uses the internal DTD subset to add a new element, postit, with a simple content model to the book DTD:
<DOCTYPE book [ <!ELEMENT postit #PCDATA > ]>
It doesn't define a place for it in the content models of the DTD nor define attributes the element might take but you'll see how to do both these things in Chapter 4.
Understanding the XHTML DTDs
XHTML is an attempt to duplicate, within the limits of XML, the functionality of HTML 4.0. Although there are subtle differences, it is largely a success. Validated HTML documents can be fairly easily converted into valid XHTML documents.
In Chapter 4, you'll explore the idea of changing the XHTML DTD to suit yourself, which allows you an opportunity to study the DTD in detail. The transitional XHTML DTD is located at the back of this book as well as on the CD-ROM that accompanies it with the filename, xhtml1-transitional.dtd. The frameset and strict DTDs are also provided as xhtml1-frameset.dtd and xhtml1-strict.dtd respectively for the sake of comparison and completeness.