DTD
Drawbacks and Alternatives
Throughout this book, we will
continue to document new growths, changes, and permu-tations 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 alter-native 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 cen-tral 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 nor-mal 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
name-spaces—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 ele-ment rules and
attribute types covered in this chapter, but these are pretty weak consider-ing
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 vali-dating 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
orga-nization 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 shortcom-ings 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.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.