This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Falling for the hype
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
This week, InfoWorld has a cover story on XML and how well the 4 major databases (DB/2, Sybase, Oracle, and SQL Server) handle it. The part I'm commenting on is in the introductory paragraph:
If you could do one thing to improve integration and automate processes with customers and business partners, it would be to implement XML, which has become the standard for exchanging information between disparate systems because it is easily transformed into any format.
Sure it is. Assuming you know what kind of schema the document is using. Simple example - say you picked up an old version of BottomFeeder and were confronted with an Atom document. heck, suppose you had version 3.1 (version 3.4 is the most recent) and wanted to deal with an Atom 0.3 document? That rev of Bf had not dealt with 0.3 yet, and the 0.2 handlers did not display information from 0.3 documents correctly. Sure, you could translate an 0.3 doc back into an o.2 doc - but would you have any idea that you should?
XML is a data format. It's no better or worse than any other format, and it's certainly not magic pixie dust - and yet publications like InfoWorld continue to present it as some kind of magic interoperability balm, ready to smooth away all problems. It's not - if you don't know what kind of doc you are getting, you aren't likely to be able to deal with it intelligently - whether it's human readable or not. XSLT assumes that you have the semantic knowledge handy to a do a transform - the simple presence of angle brackets does not grant that semantic knowledge. Here's a nice example of the magic pixie dust thinking that pervades the XML world:
For example, querying on a patient ID number in a relational database may allow you to quickly find the dates a certain patient visited the hospital, the conditions he was diagnsed with, and the treatments he was given. But it likely won't help you determine which treatments were provided for which conditions, or what times the treatments took place, nor will it give other useful information that XML versions of these records could provide
Say what? has this guy never heard of foreign keys and joins? Sure, they can get messy for complex data retrievals - but they are hardly impossible. Reporting systems are being built to handle these sorts of issues all the time. And XML records would magically solve the problem? I'd really like to know how. Apprently, applying XML will make it easy for me to solve every software integration problem I have.
The most amusing part of this is the complete lack of historical awareness. Hierarchical databases were the storage solution until the 80's. At that point, the RDBMS started to become supreme - primarily due to the large amounts of flexibility in changing the organization of data - and the greater ease in creating ad-hoc queries. What's an XML database? It's a "back to the future" kind of move, that's what. There's nothing new here except the realization that hierarchical storage of data has merits in some domains. It's no end-all be-all - if it were, the old hierarchical databases never would have gone by the boards.
Previous Topic
