Phil Howard of Bloor Research presents anargument I've heard more than once recently: "The reason why there is this trend away from pure XML storage is because advanced XML capabilities are being introduced by all the leading relational vendors." As the developers of Object Oriented DBMS discovered, he says, "the truth is that (like it or not) the market will make do with what the relational database products offer".

If analysts are already inviting themselves to the funeral of the XML DBMS, maybe we should check to see if the departed is lying quietly waiting to be buried. Perhaps like the unfortunate Lal Bihari of Uttar Pradesh in India, it been declared dead by those who would prematurely appropriate its inheritance. Here's a few arguments for their continued viability:

• It is widely believed that less than a quarter of enterprise data is currently stored in RDBMS systems. This suggests that the market is not "making do" with what the relational database products offer today, but using a wide variety of technologies.
• The main reason OODBMS didn't hit the sweet spot, AFAIK, is that they created a tight coupling between application code and the DBMS. Potential performance gains this allows can outweigh the maintenance challenges in extremely business critical, high transaction volume environments (e.g. where IBM's IMS or Software AG's Adabas DBMS still thrive), but not in the kinds of innovative, rapidly evolving environments where OODBMS got a foothold.
• XML DBMS, on the other hand, inherit XML's suitability for loosely coupling systems, applications, and tools across a wide range of environments. Phil Howard mentions "integration" as if it were a niche. That may be true in a business sense, but the ability of the XML DBMS to efficiently, scalably, and reliably power the intrinsic integration-friendliness of XML is likely to find a wide range of uses outside the "application integration" business space.
• Again AFAIK (having only played with OODBMS personally), there is relatively little portability across OODBMS systems; code written for one would be very expensive to adapt to another. Investing in the technology required one to make a risky bet on the vendor who supplied it. This created an environment where the object-relational vendors could prosper by offering only a subset of the features but the absolute assurance that they would be in business for years to come. In the XML DBMS world, on the other hand, all support roughly the same schema, query language, and API standards;
• The standards of the XML world provide a clearly defined and fairly high bar for those who would seek to take away the market pioneered by the XML DBMS vendors. For better or worse, the XML family of specs is complex and quite challenging to support efficiently in a DBMS system. It's one thing to support, as the RDBMS vendors now do quite well, XML views of structured, typed, relatively "flat" data such as are typically found in RDBMS applications. It is quite another to efficiently and scalably support queries and updates on "document-like" XML with relatively open content models, lots of recursion, mixed content, and where wildcard text comparisions are more frequent than typed value comparisons. The dominant DBMS vendors obviously have talent and money to throw at the problem, but analysts should not assume that they will surpass theese capabilities of the XML DBMS systems anytime soon.

This is not to predict the demise or even decline of the one-size-fits-all RDBMS+kitchen sink products from the dominant vendors. Microsoft's Longhorn project apparently hopes to handle much of the other 75% in an RDBMS-powered but XML-capable replacement for the filesystem. As much as one can admire this vision and expect it to be at least partially successful, there will be an awful lot of "pure" XML data out there, partly due to Microsoft's other efforts. A substantial number of developers and end-users will continue to need "pure XML" DBMS technology that handles XML extremely well, even given the availability of DBMS technology that handles all kinds of data in a "good enough" way.

Finally, it's important to consider the gap between technology mindshare among pundits and analysts, and technology deployment by businesses who need to get the job done efficiently and reliably. I'm reminded of another technology analyst who has dismissed XML itself by pointing to its similarities to IBM's IMS product, a "discarded in practice" hierarchical DBMS. So IMS is also dead, eh? Let's see ...IBM says "IMS serves 200 million end users, managing over 15 billion Gigabytes of production data and processing over 50 billion transactions every day." Another corpse that won't quietly play its part in the funeral the analysts have thrown for it!

I'm not sure when pure XML databases will be managing exabytes of data, but It looks to me like XML DBMS's will join IMS and Mr. Bihari in the ranks of those who continue to lead active and productive lives despite having been declared "legally dead" by the presumed authorities.