In my article Managing data with XML: Forward to the past? in this series, I questioned the use of XML for data...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
management. I received a critical reaction from Rick Jelliffe, who claims to be a contributor to XML. Following a brief email exchange, I wrote a three-part article as a response to his arguments and I sent him a copy, offering to include his rebuttal (which he indicated an interest in). I have not received any reply in more than a month. Here is the first part.
Jelliffe found my position on XML "pretty wild and miss[ing] the point" because XML, he argues, is just for "small, ephemeral, instantaneous data transfers between processes":
XML is just a nice, little low-level technique which has some nice properties at the current state of technology for transmitting data ... [it] was developed for entirely physical purposes: to provide a fairly rich and adaptable format for sending small collections of data between systems in a way that has some nice performance characteristics (readable, lo-tech, integrates with URLs, etc.) ... clearly some people do want XML for more than just for transmitting data. They do want XML Schemas to be the basic model for database systems. That particular sub-use of XML-related systems is fair target for concerns such as Mr. Pascal's, and I think it is very good to have vigorous discussion on them ... [but] to blanket condemn XML comes across a little hysterical (I expect this is merely the appropriate persona adopted for a series entitled Against the Grain, adopted to stimulate thought) ... Opposing XML in general and relational databases [sic] is as futile as opposing the stack, or the CRC (Cyclic Redundancy Check), or PostScript to relational databases [sic] ... It would be more productive to see how XML as a technology could enhance serious relational database implementations, or how relational analysis can improve XML, rather than spreading confusion.
The IT industry has a long and rich history of extending technologies to purposes for which they were not intended, which tends to cause more problems than it solves. Spreadsheets used for data management, object-oriented programming concepts applied to databases, using Java--originally intended for appliances--for general-purpose programming, and the use of the browser as an all-purpose application are just some examples that come readily to mind. Often the implementation of technologies distorts them beyond recognition and diminishes their usefulness, as is the case with relational technology being implemented in the form of SQL. This will continue for as long as the industry dismisses, ignores and flouts a sound, scientific foundation in its practices (see my first article in this series, as well as most of the material at my site Database Debunkings.
Given industry practices, perhaps some hysteria is warranted. Be that as it may, Jelliffe seems more hysterical about my criticism than I am about XML. One cannot oppose industry fads. What is more, I submit that a relational analysis of XML is exactly what my article offers, and that the analysis raises questions as to the ability to improve XML, and about XML's potential to enhance relational database implementations. XML authors should have considered the implications for data management in general, and relational database management in particular, when they invented XML. Not having a background in the field, they did not.
The effort and resources invested in XML data management have gone much beyond "some people". As Jelliffe himself admits, the number one question he gets from people in seminars is "Is XML a database?" and "Will XML supplant the DBMS?" Little wonder: there are tons of mind-numbing W3C standard specification efforts--including XML Schema, a XML Query Language and many others which clearly fall into the data management domain, each with their authors and proponents unaware that they do. Eager to ride the latest fad, the database side of the isle proliferates material such as Schema, query: Is it database or XML? and Modeling relational data in XML. Jelliffe puts all this down to "inexperience". I would argue that even very experienced database practitioners don't have sufficient knowledge of the fundamentals to appreciate the implications, let alone XML inventors and proponents, who have little or no database experience at all. (One indication: markup tags do not a language make. Despite its name, XML is not a language!).
To Be Continued...
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
- What do you think about this tip? E-mail us at editor@searchDatabase.com with your feedback.
- The Best XML Web Links: tips, tutorials, and more.
- The Best Database Design Web Links
- Have an XML or database design tip to offer your fellow DBA's and developers? The best tips submitted will receive a cool prize--submit your tip today!
- Do you have any technical questions about XML? Post them--or help out your peers by answering them--in our live discussion forums.
- Check out our Ask the Experts feature! Our database design and SQL gurus will answer your toughest design questions.