Tip

Managing data with XML: Forward to the past?

The inventors of XML, Jon Bosak and Tim Gray, described in a Scientific American article the problem that their invention was intended to solve as follows:

    Requires Free Membership to View

"[There is] difficulty in creating a Web site that functions as more than just a fancy fax machine that sends documents to anyone who asks. People and companies want Web sites that take orders from customers, transmit medical records, even run factories and scientific instruments from half a world away. HTML was never designed for such task ... in essence, it describes how a Web browser should arrange text, images and push-buttons on a page... [And while] ... people can look at this page, see some large type followed by blocks of small type and know that they are looking at the start of a magazine article [or t]hey can look at a list of groceries and see shopping instructions [or t]hey can look at some rows of numbers and understand the state of their bank account, [c]omputers, of course, are not that smart; they need to be told exactly what things are, how they are related and how to deal with them." [emphasis mine]

What the authors are talking about here is nothing but database management. And, in fact, telling "what things are, how they are related and how to deal with them" is the very function of a data model, a theory of data that conveys semantics--what data means--to the DBMS, such that it can "take orders, transmit medical records, even run factories and scientific instruments" from users via applications.

Even leaving the very important issue of what data model, if any, underlies XML, note very carefully: in a database environment, the meaning (conveyed by any data model) is declared (by database designers) to the DBMS. It is the DBMS that has this knowledge and manages data accordingly, on behalf of user applications (integrity enforcement, data manipulation, physical retrievals/updates and optimization, etc.). Indeed, the whole point of database management is to centralize these functions in the DBMS, away from file-processing application programs, because the latter are not cost-effective.

But now consider the XML 1.0 specifications:

"A software module called an XML processor is used to read XML documents and provide access to their content and structure. It is assumed that an XML processor is doing its work on behalf of another module, called the application. This specification describes the required behavior of an XML processor in terms of how it must read XML data and the information it must provide to the application." [emphasis mine]

There is no DBMS here! Rather, all the intelligence--the semantics--is back in application programs! Here are Bosak and Bray again:

"... imagine going to an on-line travel agency and asking for all the flights from London to New York on July 4. You would probably receive a list several times longer than your screen could display. You could shorten the list by fine-tuning the departure time, price or airline, but to do that, you would have to send a request across the Internet to the travel agency and wait for its answer. If, however, the long list of flights had been sent in XML, then the travel agency could have sent a small Java program along with the flight records that you could use to sort and winnow them in microseconds, without ever involving the server. Multiply this by a few million Web users, and the global efficiency gains become dramatic." [emphasis mine]

Whatever "dramatic global gains" are achieved by XML data management, if any, there is ample experience to indicate that they are likely to be overwhelmed by the gross inefficiency of regressing from centralized database management back to file-processing application programs, which was discarded years ago. Something to keep in mind when bombarded with hype.

About the Author

Fabian Pascal has a national and international reputation as an independent database technology analyst, industry critic, consultant, author and lecturer. For more than 13 years he held various analytical, and management positions in the private and public sectors, was affiliated with Codd & Date, has taught and lectured at the business and academic levels, and advised vendor and user organizations on database technology and implementation. He is co-founder and editor of Database Debunkings, a web site dedicated to dispelling prevailing fallacies and misconceptions in the database industry, with C.J. Date as senior contributor. He has contributed extensively to most trade publications, and his third book, Practical Issues in Database Management--A Guide for the Thinking Practitioner, was recently published by Addison Wesley.

For More Information


This was first published in January 2001

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.