More DTD Directives
Just a few more DTD keywords are left to cover. These are keywords that do not neatly fit into any particular topic, so they’re lumped together here. These keywords are INCLUDE and IGNORE, and they do just what their names suggest—they indicate pieces of markup that should either be included in the validation process or ignored.
The IGNORE Keyword
When developing or updating a DTD, you may need to comment out parts of the DTD that are not yet reflected in the XML documents that use the DTD. You could use a nor-mal comment directive (which will be covered in the next section), or you can use an IGNORE directive. The syntax for IGNORE is shown in Listing 3.19.
LISTING 3.19 Using IGNORE Directives
This is the part of the DTD ignored ]]>
You can choose to ignore elements, entities, or attributes. However, you must ignore entire declarations. You may not attempt to ignore a part of a declaration. For example, the following would be invalid:
<!ELEMENT Employee <![ IGNORE (#PCDATA) ]]> (Name, Address, Phone) >
In this example, the DTD author has attempted to ignore the rule #PCDATA in the middle of an element declaration. This is invalid and would trigger an error.
The INCLUDE Keyword
The INCLUDE directive marks declarations to be included in the document. It might seem interesting that this keyword exists at all because not using an INCLUDE directive is the same as using it! In the absence of the INCLUDE directive, all declarations (unless they are commented out or enclosed in an IGNORE directive) will be included anyway. The syntax for INCLUDE, as shown in Listing 3.20, is very similar to the syntax for the IGNORE directive.
LISTING 3.20 Using INCLUDE Directives
This is the part of the DTD included ]]>
The INCLUDE directive follows the same basic rules as the IGNORE directive. It may enclose entire declarations but not pieces of declarations. The INCLUDE directive can be useful when you’re in the process of developing a new DTD or adding to an existing DTD. Sections of the DTD can be toggled between the INCLUDE directive and the IGNORE directive in order to make it clear which sections are currently being used and which are not. This can make the process of developing a new DTD easier, because you are able to quickly “turn on” or “turn off” different sections of the DTD.
Comments Within a DTD
Comments can also be added to DTDs. Comments within a DTD are just like comments in HTML and take the following syntax:
<!-- Everything between the opening tag and closing tag is a comment -->
As in HTML, comments in a DTD may not be nested. Comments may, however, span multiple lines. Generally comments in a DTD are used to demarcate different sections of the DTD or to help human readers understand different abbreviations used in the declarations. Comments will be ignored by the XML parser during processing. Listing 3.21 shows how to insert comments into a DTD.
LISTING 3.21 Using Comments
<!-- This is a comment -->
<!ELEMENT rootelement (element1, element2)>
<!ELEMENT element1 (#PCDATA)>
<!-- This is another comment -->
<!ELEMENT element2 (#PCDATA)>
<!-- This is a comment that spans multiple lines -->
Comments provide a useful way to explain the meaning of different elements, attribute lists, and entities within the DTD. They can also be used to demarcate the beginning and end of different sections in the DTD.
The DTD is a powerful tool for defining rules for XML documents to follow. DTDs have had and will continue to have an important place in the XML world for some time to come. However, DTDs are not perfect. As XML has expanded beyond a simple docu-ment markup language, these limitations have become more apparent. XML is quickly becoming the language of choice for describing more abstract types of data. DTDs are hard-pressed to keep up. We will now take a look at some of the drawbacks to DTDs and what future alternatives will be available.