Ever tried to read a DTD, and failed miserably? Ever wondered what all those symbols and weird language constructs meant? Well, fear not - this crash course will get you up to speed with the basics of DTD design in a hurry.
Once you have an XML document and a DTD linked together, an XML parser can verify the document against the DTD and let you know if it finds errors. A number of tools are available online to perform this validation - my favourite is the XML Spy editor, available at http://www.xmlspy.com/ , although you can also try out expat, at http://sourceforge.net/projects/expat/, and rxp, at http://www.cogsci.ed.ac.uk/~richard/rxp.html
Here's what rxp has to say when I run it on the XML document above.
While this version of the document is still well-formed, it no longer follows
the rules laid down in "weather.dtd" and hence cannot be considered valid - which is why rxp barfs and generates a list of errors.
$ rxp -V weather.xml
<?xml version="1.0" encoding="UTF-8"?>
Warning: Start tag
for undeclared element weekly_mean
in unnamed entity at line 7 char 14 of weather.xml
Content model for weather does not allow element weekly_mean here
entity at line 7 char 14 of weather.xml
Warning: Start tag for undeclared element daily_forecast
in unnamed entity
at line 8 char 17 of weather.xml
Incidentally, it's also possible to place the DTD within the XML document itself.
Although this is quite rare - the DTD is usually stored in a central place so that it can be referenced by different XML documents - you should know how to do it in case you're ever home on a Saturday evening and feel like experimenting.