Re: Dreaming About Redesigning SQL

Sailesh,

Warning: I get carried away in this response. I'm afraid that I'm a fond
reader of Fabian Pascal and CJ Date, so I have far too much to say on the
topic. So if you really care about XML databases, you should probably hold
off on reading the rest until you're well-caffinated and in a cheerful frame
of mind.

Also, let me clarify that there is a distinction between using XML *as a*
database, and putting XML documents into databases of other types. I find
the latter obvious and sensible, but the former a silly and wrong-headed
idea, and it's the pure-XML-database which I attack below.

If you want to really have this out, I live in San Francisco and I love to
argue. Coffee at Intermezzo? I'll buy.

-------------------------------
> If you look at the academic research work, there have been gazillions
> of recent papers on XML database technology.

Point me to one which presents an algebra, calculus, or other mathematical
underpinning of XML databases, and I will be happy to eat my words on this
list. I can easily find lots of papers using google, but all of them are
about *technical implementation* and do not provide a theoretical
underpinning for XML databases.

A few (such as Dan Suciu's paper) present some theory to back XQuery but it is
presented entirely as an XML-based data access extension to SQL ... a role
which seems fine to me.

Others, even those cited by xmldb.org like the below, have rather lukewarm
things to say on the topic, such as David Mertz, PhD:
(http://www-106.ibm.com/developerworks/library/x-matters8/index.html)

"XML is an extremely versatile data transport format, but despite high hopes
for it, XML is mediocre to poor as a data storage and access format. ..."
<snip>
" ...XML has no inherent mechanism for enforcing constraints of this sort
(DTDs and schemas are constraints of a different, more limited sort). Without
constraints, you just have data, not a data model (to slightly oversimplify
matters). ..." <snip>
" ... In other words, go ahead and be excited by XML's promise of a universal
data transport mechanism, but keep your backend data on something designed
for it, like DB2 or Oracle (or on Postgres or MySQL for smaller-scale
systems)."

And this guy is cited by XMLDB.org? Perhaps not surprising, as among the 5
goals of XMLDB.org, development of a standard theory of XML databases is not
present.

> All the major database
> vendors (Oracle, IBM and Microsoft) are investing fairly heavily in
> core-engine XMLDB technology.

So? Oracle, IBM and Microsoft also have SQL databases that do a terrible job
of upholding the SQL standard, and their (at least Oracle's and Microsoft's)
adherence is getting worse with successive versions rather than better. I
wouldn't look to them for guidance.

If they're spending millions on XML Databases, it's becuase it, however
wrong-headed, is a fad and fads mean sales, and they don't want to take a
chance on missing out. And these companies have backed plenty of useless
technologies before; remember Microsoft's "Periodicals on CD"?

Not that I'm against XML; as far as I'm concerned, for interchangable,
searchable, and archival documents, XML is the greatest thing since sliced
Beatles. I love XML-RPC for pushing data through HTTP, and I will happily
be in the cheering squad for anyone who writes a set of OSS tools to extract
data from XML docs stored in a PostgreSQL database, or to automate
some-standard-XML-to-relational-data-and-back conversion. That is a good
application of XML+Database ideas.

XML databases, on the other hand, are an example of taking a good idea too
far. XML is a great data transmission tool; it's a great document
transformation tool; it's a good way to store documents. It is not,
however, a good database.
------------------------------------------------------
--
Josh Berkus
Aglio Database Solutions
San Francisco