My role in the company I work for is that of both software engineer and DBA. That being the case, I had mixed feelings about the article - applauding some of the points made, wondering whether the wider issue was missed with others.

One of the biggest struggles I have with the developers I work with is to get them to think relationally first, object oriented second. Similarly, because of the hierarchic nature of XML, I have the same struggle! I personally do not feel you can get the richness in meaning availble to RDBMSs in XML. Anybody who has tried mapping a many-to-many relationship in XML knows just what I mean. That, and I have a firm belief that good software flows naturally out of a good database design.

So using XML to hack the relational model is b-a-d. However, using XML to map to a relational model is not necessarily evil.

The argument that if tags change that everything breaks is true, however, why would the tags change? The same is true if you rename a field within a table or change its datatype. You just don't do it, or at least not without significant impact analysis.

But there are many advantages to XML too. First and foremost, it's a standard. It has its faults (as pointed out in the article) but nonetheless, it is a standard. Developers have no need to reinvent the wheel on each project - the same toolset can be used across all projects to carry out the most standard of tasks. Standardised and generally bug-free too. Also, XML data feeds facilitate more meaningful code. You're getting the product's colour in your code rather than the first item in a CSV list. Anything that allows people to write precise and concise software that *works* is a gift.

There is the argument that data processing should be distinct from data transport. That's generally because firstly we humans think better in terms of distinct layers, plus data transport rarely has problems, in comparison to data processing at least. But the fact is that no database exists in isolation. If one part of the system fails, the system is seen to fail as a whole, and the fault you refer to should be shared by all - not just the database guys, the programmers or their respective methodologies. It's the business failure that hurts, not the technical failure.

I wonder why people do not worry about ADO or (especially) ADO.NET as they do XML? Both means require the transport of metadata as well the data itself, yet this is usually fine? Maybe if there were something more mystic about XML than just plain text people would have more belief in its capabilties.

I had to smile at the "ignorance" claim, simply because I think we all know just what the author means! Why the hell do we need an XML data service on a biscuit tin anyway?

I think the additions of "stupidity" and "greed" don't give a balanced representation of the vendors' position though. There are genuine benefits to vendors in terms of widening hardware and software capabilities whilst reducing implementation overheads. Take, for example, set-top boxes. These are capable of using the same ROM-based XML APIs for multiple purposes, using one communications protocol (HTTP) without the need to implement ODBC connectivity. This allows manufacturers to fit more data-rich services in the same storage space, minimising the quantity of service-specific data manipulation routines, and without storing drivers for every concievable database out there.

I think the conclusion I draw is that XML data services using an RDBMS as a backend have their places and uses. They do not fulfil every need there's ever been, so no, don't believe the marketing hype. But don't dismiss it either - you could find yourself talking yourself out of a valid and efficient wider system, given the right context.