- The Need for Alternatives
- Document Type Definitions (DTDs)
- RELAX NG
- Schematron
Document Type Definitions (DTDs)
Just because the W3C built it, that doesn't mean that you have to use it. Sometimes it may be perfectly reasonable to stick with the DTD you're currently using. Obviously, if your DTD is functional and you don't have any need to extend it, chances are that you might be better off leaving well enough alone. But there are still some reasons to use a DTD even when developing a new schema from the ground up, as shown in the following table.
Situation |
Explanation |
When brevity matters |
By design, DTDs tend to be more concise than XML Schemas. XML in general is not designed for brevity; it's a verbose language, which is part of what helps make it more human-readable. If brevity is important, you might be able to accomplish your goals with a DTD instead of a schema. |
When you want users to be able to override definitions easily |
With DTDs, redefining or overriding declarations can be pretty easy. It can be done within the DTD itself using parameter entities, and it can be done in the DOCTYPE itself. For example, the DOCTYPE declaration used to link an XML document to the DTD can also contain internal element declarations, attribute declarations, and so on. If those internal DTD declarations are in conflict with the declarations in the external DTD, the internal declarations are used instead. The dual internal/external DTD sets make it very easy to manipulate the DTD by extending or overriding the declarations. Of course, XML Schemas have methods to "import" or "include" other XML Schemas; however, doing so is not necessarily trivial, and because of namespace issues can be quite complex. If you're using a base schema, but need to easily override or extend that schema, a DTD might be a better choice than XML Schemas. |
For large, mostly text documents |
Everyone talks about the power of XML Schemas, especially the power of datatypes. And it's true that datatypes offer a high degree of flexibility and power that wasn't possible with DTDs. But not everyone needs that kind of flexibility and power. What if your needs center around large-scale documents, which are mostly (if not entirely) text? Some examples might include manuals, documentation, or encyclopedia-like documents. While these might have some elements used for indexing and cross-referencing, the majority of the elements might simply contain large blocks of text. If your uses for XML are mostly large blocks of text, you might just stick with DTDs. Unless there's a compelling schema feature that's essential to your document needs, a DTD may satisfy your schema requirements adequately, and quite possibly more efficiently. |
When your tools don't support schemas |
XML Schemas are fairly new technology. If the tools you rely on everyday to be productive don't support XML Schemas, you might have to stick to DTDs for a while. That doesn't mean you can't think about XML Schemas, or learn how you might use them in the future. But in the meantime, if your software doesn't support XML Schemas, it won't do you much good to use them. |