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

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

> -----Original Message-----
> From: XML Everywhere [mailto:host@xmleverywhere.com]
> Sent: Friday, October 19, 2001 11:50 PM
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] XML Database Decision Tree?

> Native XML databases have no chance
> until schema, transactions, query, extraction, bulk load, 
> and data transformation are all reasonably
> standardized.   Which _isn't_ going to happen 
> in our lifetimes, unless you're a ten year old.

> There is no vendor out there who is ready to fill the shoes
> of an Oracle or a SQL Server or a DB2.


> But native XML DBMSs are
> not appropriate for most ISVs, at least 
> for the foreseeable future.

Two months ago, no one would have said that anthrax testing kits would be
hot consumer items "in the forseeable future." Five years ago, few thought
that XML would be an important technology "in the forseeable future."  Ten
years ago, few thought that HTML would be of commercial interest "in the
forseeable future." Twenty years ago, no one thought Microsoft was "ready to
fill the shoes of IBM". In other words, the future isn't all that
forseeable, so let's not kid ourselves that the conventional wisdom today
provides much insight into the reality of tomorrow.
 

That sermon out of the way :~) I'll do my own soothsaying ... I think what
will happen with both XML and XML DBMSs is that they will become "co-opted"
(a '60's word you don't hear much anymore) by the mainstream and fade into
the conventional wisdom themselves.  As Tim Bray (I think) said, in a few
years it the thought of an "XML conference" may be as absurd as an "ASCII
conference" today.  

That's not to say that XML as we know it today will dominate, just that it's
best ideas will be stolen shamelessly, combined with others, and
re-packaged. It will probably be seen as a precursor to whatever the
dominant thing is, perhaps like we see Algol/Pascal as a precursor to C and
Java. Or, perhaps, as we see Poet or ObjectStore among the precursors to the
Object-Relational features in Oracle/SQL Server/DB2.   Similarly with XML
DBMSs:  If in five years the currently dominant RDBMS vendors support
automatic XML schema import/conversion tools,  seamless XML instance
shredding/storage capabilities, and XQuery as a query language, what will
distinguish them from "native XML" DBMSs? Oracle 9i already has a "native
XML SQL type".  "Native XML DBMSs" will be around, although we may not CALL
them that; we call Oracle 9i an RDBMS, but it is (to some extent, although
I'm sure the marketing people at Poet and Object Design would dispute this)
also an OODBMS, and I suspect that 10i or 11i will also be an XML DBMS.

So, I suspect that ISVs would be very well advised to bet on native XML DBMS
concepts and technology. Vendors are another matter entirely, and I won't
even pretend to read the entrails here.  As I've predicted, the currently
dominant vendors DBMS will probably add "native" XML capabilities.  The
question is whether someone will come out of left field with a new
conception of how the relational model and hiearchical/network data model(s)
implied by XML/RDF/etc. can be elegantly subsumed by something To Be
Determined, and then go on and effectively market it to customers
overwhelmed by the complexity of the current stuff + XML + godknowswhatelse.
The TBD model and the TBDCorp may be enshrined in the conventional wisdom in
5 or 10 years, or it may still be Bill and Larry calling the shots. I dunno.
Place your stockmarket bets on whoever you want, but place your technology
bets on the Web and XML specs that actually work today or show signs of
actually working soon.  That's all that "native XML" advocates are saying at
one level, whatever companies we're betting on at another.