Debugging the DTD

Model editing

There is often a number of different ways that the legal content of an element can be specified. But in all cases, the most terse and efficient alternative should be chosen, as this approach reduces ambiguity. The following is a list of some of the most common mistakes:

good practice               bad practice

(a+)            instead of  (a, a*)
(a*)            instead of  (a?, a*)
(a | b)?        instead of  (a? | b?)
(a, b, c, d)    instead of  (a, (b, c), d)
(a, b?, c?, d)  instead of  (a, (b?, c?)?, d)
((a | b), c)    instead of  ((a, c) | (b, c))

Badly designed models have been seen in many publicly released DTDs. They cause confusion because they tend to imply that some other model was intended, and cast doubt on the quality of the model itself.

Syntax testing

When a DTD has been developed using a standard text editor, it may contain errors. The first and most obvious kinds of error are syntax errors in the markup tags. Missing chevrons or keywords are detected and reported by XML parsers. Validating parsers will also detect such errors as content models that refer to elements which do not exist.

Model testing

The time needed for testing the document model defined by the DTD is often underestimated. Even relatively simple DTDs usually contain a surprising number of possible document structures. Even if a DTD design tool is not used to construct the DTD, these tools can be useful for revealing content models in a tree form that is easy to analyse.

Testing should also involve the production of conforming documents that contain all possible combinations of elements. This process should reveal any gaps or redundancies in the structure, and the resulting documents become a useful product for the purposes of training future authors and editors. If realistic data is placed in this document, it may also be used to test translation software and stylesheets.