Testing Your Work

DTDs, by their nature, contain many complex, interrelated elements. Whenever you make a change to the DTD, it's always wise to use a validating parser to double-check your work. A parser like nsgmls from James Clark's SP can identify elements (attributes, parameter entities) that are declared but unused, as well as ones that are used but undeclared.

A comprehensive test can be accomplished with nsgmls using the -wall option. Create a simple test document and run:


nsgmls (1)-sv (2)-wall test.sgm
(1)
The -s option tells nsgmls to suppress its normal output (it will still show errors, if there are any). The -v option tells nsgmls to print its version number; this ensures that you always get some output, even if there are no errors.
(2)
The -wall option tells nsgmls to provide a comprehensive list of all errors and warnings. You can use less verbose, and more specific options instead; for example, -wundefined to flag undefined elements or -wunused-param to warn you about unused parameter entities. The nsgmls documentation provides a complete list of warning types.

DocBook V3.1 Warnings

If you run the preceding command over DocBook V3.1, you'll discover one warning generated by the DTD:


nsgmls:I: SP version "1.3"
nsgmls:cals-tbl.dtd:314:37:W: content model is mixed but does not allow #PCDATA everywhere

This is not truly an error in the DTD, and can safely be ignored. The warning is caused by "pernicious mixed content" in the content model of DocBook's Entry element. See the Entry reference page for a complete discussion.