RE: [xml-dev] XML Database Decision Tree?

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

> -----Original Message-----
> From: Tim Bray [mailto:tbray@textuality.com]
> Sent: Monday, October 22, 2001 1:01 PM
> To: Champion, Mike; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] XML Database Decision Tree?
> 
> 

> 
> So....... Mike, perhaps you and some of the other XDBMS purveyors
> could give us some examples of the places this stuff latches onto?

The canonical example is someone who enlists in the XML Revolution and finds
that XML is too much of a good thing:  too much volume to store in a
filesystem or conventional web server, too much "extensibility' (i.e.
heterogeneity) to normalize into a conventional DBMS, too much importance to
throw away, and having too much promise to hide away.  So, they put it in an
XML DBMS, build forward-facing applications using DOM/XSL/etc. and build
backwards-facing interfaces using all sorts of proprietary stuff that nobody
else needs to care about anymore.

I came out of the document world; I latched onto it because an XML DBMS made
sense as a way to traditional SGML-style document/content management using
SGML-open catalogs, external entities, etc. on top of a reliable, queryable
back end without having to change much of anything. The ability to query
actual content with XPath-like queries rather than extracting metadata to a
separate repository was the "scales falling from the eyes" experience for
me; not to mention the fact that I had spent the previous few years
wrestling with various high-end document management systems, and an
XML-aware database interface that could be put together in man-hours rather
than man-years had a certain appeal ...

Other (generalized, for obvious reasons) examples that the XML DBMS meme has
successfully latched onto include:

- Staging Servers: Hide the godawful mess in the back office behind an XML
representation cached in an XML DBMS so that other applications  don't have
to know or care about the voodoo behind the scenes.  

- Multi-format content servers: Use DOM programs or XSLT stylesheets, and/or
just attach a CSS stylesheet, to present an XML "database of record" into
various display formats such as HTML, XHTML-basic, WML, and whatever
buzzword-du-jour-ML comes along next. 

- glorified transaction logs: if the godawfulmess in the back office is
glued to the buzzword-du-jour-ML's out on the wireless web somewhere via
some tangled mess of CGI/ASP/JSP/SOAP triggered by diverse XML B2B/B2C/A2A
messages, how will you ever keep track of what is really going on from a
point of view that management cares about, or to give customers a coherent
answer when the widget they ordered from your virtual store didn't show up,
but the credit card statement did?  Logging the "transient" XML data can
help.

- Next-generation object databases:  People still need to persist the state
of their objects, the OODBMS have lost mindshare/development support, and
the need to share the objects between versions of some class definition,
different programming languages, etc. makes the job even harder as time goes
on.  Serializing to XML provides a vendor/language/version-neutral format
that is a) reliable/transactionable/backup-able; b)queryable by something
other than object id, c) readable in principle by someone having to debug a
problem, and d) supported by all vendors (e.g., Java's XML serialization
support in JDK 1.4) and understood by random employees. 


Perhaps the other "canonical" example of when people choose an XML DBMS --
it is the "middle way" between throwing out the data (or dumping it into a
huge logfile or backup tape, which is effectively the same thing) on one
hand and building a full-blown RDBMS application to manage it on the other.