Why Use a DTD?

We've already discussed that you might want to make use of a DTD to enforce rules in an XML document. That is the generic case for using a DTD. Here are some specific instances in which you may want to use a DTD to create valid XML documents.

Using a Predefined Markup Language

Let's say you are using the Chemical Markup Language (CML) to define some molecular structures in an XML document. The CML is a markup language that has been defined to make it easy to exchange chemical data among chemists. Therefore, it's important that they all utilize the language in the same way. If authors were to apply the CML in different ways, they would not be able to ensure that everyone's CML documents were compatible or made sense. So, this is a perfect time to use a DTD.

Anytime you are using an XML vocabulary that is based on a Web standard or industry standard, it's a good idea to use a DTD to ensure compatibility. Now, the upside of using existing DTDs is that you don't have to write them. In the case of using a standard DTD, you will most likely just be using the DTD to validate the content of your documents.

Consistency

Let's say that you are writing a document to catalog books in a library. You might want to make sure that each of the XML entries for books is in the same format. Chances are you will use some standard method of cataloging, such as the Dewey Decimal System. You could rely on your talents and attention for detail to make sure each record is complete and accurate. However, that leaves you open to potential problems. After all, even the most diligent author sometimes makes mistakes.

By using a simple DTD that outlines what elements and attributes must be used in your XML records, you can make sure that every one of your records is completed correctly, without having to worry about paying strict attention to each record you author. If they're filled out incorrectly, the record won't validate, and then you can correct the problem before proceeding.

Collaborative Authoring

The problem of consistency or data integrity is also a concern when working in a collaborative environment. Because you cannot always rely on everyone to be as data savvy and conscious as you, DTDs and validation offer a method for making sure that everyone is entering the data in their XML documents in the same way, and that their data is good after it is entered into the document. This can be a real lifesaver if you are entering huge amounts of data. Imagine having a workgroup entering thousands of records. If they aren't all good, tracking down the bad data could easily consume more time than authoring a simple DTD.

Highly Structured Documents

Some documents are built to be flexible, and some are not. If you are building an XML document-based CD catalog for your record collection, you might not care too much about data integrity or structure. But if you are building a part description for an engineering project, data integrity is a much more important issue.

For highly structured or very data-intensive applications, DTDs can help force users to be complete in their documents, and they can help make sure the documents are structured logically and usefully.

As you can see, there are several instances in which DTDs can be very helpful, if not necessary. And the examples we've provided here are by no means all the reasons you might want to use a DTD. The best gauge of when to use a DTD or not will be your own judgment, based on what you need from your documents and what you feel you can accomplish in the DTD.