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 |
-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.-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.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.