DTD Structure

DTD Structure

Now that you have an understanding of how to reference a DTD, the next step is to understand how DTDs describe XML documents. The first element in a DTD is usually an XML declaration, even though most of the other elements in a DTD do not look like well-formed XML. This is due to the special syntax rules for DTD documents. Each element in a DTD must have an exclamation mark as the first character in the element name. All other XML syntax rules apply to the element name.

DTD Declarations

There are four declarations that can be used in DTDs: ELEMENT, ATTLIST, ENTITY, and NOTATION. Although the elements conform to the rules of well-formed XML, in a DTD elements that start with a ! are referred to as DTD declarations. This is to separate the description of XML documents from the documents themselves, and also because one of the four declaration types is called ELEMENT, and references to the ELEMENT element would make DTD documentation start to sound like Monty Python’s “Department of redundancy department” sketch.

The ELEMENT declaration describes XML document elements and optional nested elements. The ATTLIST declaration describes XML document attributes and optional values. The ENTITY declaration describes special characters and references to variables, and is the same as the entity references in XML documents that I discussed in Chapter 2. The Notation declaration is used to contain references to external data such as URLs to an image in a DTD. In addition, comments can be contained in a DTD using the same format as XML document comments.

It’s worth noting that the DTD I am using in this example is edited, but not generated by, xmlspy. While xmlspy has a very good facility for generating DTDs, probably the best on the market, in this case a DTD already existed that was muchsimpler than the one generated by xmlspy. Naturally, the simpler and more readable DTD was chosen and cleaned up using xmlspy’s editor. The moral of the story is that even though many tools can generate DTDs, developers still need to know something about DTD structure if they want to make sure that the DTD that was generated is doing the best job possible in validating XML document data, or to repurpose a generated DTD if there is a problem with it. In other words, you can’t skip this chapter just because you know about tools that generate DTDs! The example DTD in Listing 3-1 starts with an XML declaration then contains a comment that tells us that this DTD was edited using xmlspy.