- Document Type Definitions
- Some Simple DTD Examples
- Structure of a Document Type Definition
- DTD Drawbacks and Alternatives
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
DTD Drawbacks and Alternatives
Throughout this book, we will continue to document new growths, changes, and permutations to XML as a technology to enhance data exchange, data structuring, e-commerce, the Internet, and so on. As newer uses for XML come into being, the needs for validation expand. XML is being used to describe the data structure of video files, audio files, and Braille devices, among other things—not to mention the ever-growing plethora of alternative data devices such as cellular phones, handheld computers, televisions, and even appliances. There are several drawbacks that limit the ability of DTDs to meet these growing and changing validation needs.
First and foremost, DTDs are composed of non-XML syntax. Given that one of the central tenets of XML is that it be totally extensible, it may not seem to make a lot of sense that this is the case for DTDs. However, you must consider that XML is a child of SGML, and in SGML, DTDs are the method used to validate documents. Therefore, XML inherited DTDs from its parent. Although DTDs are effective at defining the structure for document markup, as XML evolves, the fact that DTDS are not formed of XML syntax and are nonextensible becomes constraining.
Additionally, there can only be a single DTD per document. It is true that there can be internal and external subsets of DTDs, but there can only be a single DTD referenced. In the modern programming world, we are used to being able to draw the programming constructs we use from different modules or classes. If we applied this idea to DTDs, we might expect to be able to use a DTD for customers, a separate DTD for inventory, and a separate DTD for orders. However, this is not the case. All aspects of an XML document must be within a single DTD. This limitation is similar to what programmers faced back in the days of monolithic applications before object-oriented programming became a normal standard for application development. This leads into the next limitation.
DTDS are not object oriented. There is no inheritance in DTDs. As programmers, we have gotten used to describing new objects based on the characteristics of existing objects. One classic example is having Porsche, Ford, and Chevrolet classes that inherent some characteristics from a base car class. DTDs have no capability to do this.
DTDs do not support namespaces very well. For a namespace to be used, the entire namespace must be defined within the DTD. If there are more than one namespace, each of them must be defined within the DTD. This totally defeats the purpose of namespaces—being able to define multiple namespaces from many different external sources.
Additionally, DTDs have weak data typing and no support for the XML DOM. DTDs basically have one data type: the text string. There are a few restraints, such as the element rules and attribute types covered in this chapter, but these are pretty weak considering the types of applications for which XML is now being used (especially in e-commerce). The Document Object Model has become a powerful tool to manipulate XML data; however, the DTD is totally cut off from the reach of the DOM.
Finally, and possibly most important from a security standpoint, is the ability of the internal DTD subset to override the external DTD subset. An company could spend a great deal of time and effort crafting a DTD to validate the XML data in its e-commerce transactions only to have the settings in the DTD overridden by the internally defined elements of a DTD. The implications on this from a transaction security standpoint should be fairly clear.
So, what is to be done about the DTD? The DTD is still an effective mechanism for validating XML documents and will be so for a long time to come. It just does not "scale" to meet the needs of the expanding XML world. At the time of this writing, the W3C organization has just recently finished the final touches on the recommendation for the XML Schema, which is a new validation mechanism for XML that corrects all the shortcomings of DTDs. XML Schema is a powerful and important technology for the future of XML. The next chapter of this book will be devoted to covering the XML Schema.
NOTE
The W3C organization's Web resources page for the XML Schema may be viewed at http://www.w3.org/XML/Schema.