Document Type Definitions

If the W3C XML Schema Language is a Torx screwdriver, then DTDs are the old reliable flathead screwdriver, not nearly as sexy but a lot more practical and a lot easier to find at the corner store. Contrary to popular belief, schemas do not replace DTDs. DTDs are an extremely well- tested , well- understood , broadly supported, compact syntax for expressing constraints on XML documents. Furthermore, DTDs can do things that none of the other schema languages can accomplish, notably entity definition. Finally, a document can have both a schema and a DTD.

Don't reject DTDs simply because they're not as hip as schemas. Indeed, if your constraints are limited to the element and attribute structure of a document and do not involve PCDATA and attribute values, a DTD can do almost anything a W3C XML Schema Language schema can doand do it a lot more simply, robustly, and compatibly.

Key features of DTDs include the following:

• Very broad parser and library support

• Extensive support for parentchild structures

• The ability to define entities and notations

• Default values for attributes

DTDs are most appropriate when:

• Documents are narrative-like, with lots of mixed content.

• Most validation is concerned with element and attribute structure, not with the content of elements and attributes.

• You need to define entities.

• Ease of schema authoring is a primary concern.

• Document producers and document consumers can agree on the schema to use.

DTDs are least appropriate when:

• Validation is concerned with the internal structure of PCDATA and attribute values (as opposed to the external structure identified by tags).

• Data typing is desirable.

• The order of child elements doesn't matter but the number of them does.

• Element constraints are based on sibling, ancestor , or descendant relationships rather than parentchild relationships.

• The namespace prefix is not consistent across documents.

• The schema to apply is chosen by something other than the instance document itself.

In brief, DTDs work best for the sorts of documents they were originally designed for when the SGML community invented them: narrative documents intended ultimately for human consumption in which all text content is basically a string. It's not really surprising that they work less well for applications that postdate them and weren't really conceived of yet when DTDs were invented: namespaces, object serialization, database exchange, vector graphics, and other computer-focused applications with strong typing requirements. But just because DTDs don't fit these new applications perfectly is no reason to discount them for the applications they were designed for, which they fit very well.