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

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

> -----Original Message-----
> From: Dan Weinreb [mailto:dlw@exceloncorp.com]
> Sent: Saturday, October 27, 2001 2:52 PM
> To: nicolas.lehuen@ubicco.com
> Cc: Mike.Champion@SoftwareAG-USA.com; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] XML Database Decision Tree?
> 
> 
> (Also, XML documents in XIS aren't required to have prescriptive
> schemas.  So if your position was that you didn't want a prescriptive
> schema in the first place, but just wanted to allow any well-formed
> XML, XIS can work that way too.  But I guess you were referring to
> cases where you do want a prescriptive schema and then you want to
> change it.)


This is true in Tamino, and several other XML DBMS as well.  Some don't have
any concept of a "prescriptive" schema.

I don't know what I can and can't say about Tamino, so I'll stick to
publicly available material on DBMS implementation: You don't need a schema
to define an efficient XML indexing/querying strategy.  There's a design
pattern that, very crudely, involves storing element content in one "table"
and the XPaths to each element in another. For example, the Monet DB
http://www.cwi.nl/htbin/ins1/publications?request=abstract&key=ScKeWiWa:WEBD
B:00 (as I recall it, anyway) does something very much like this, and Simon
Williams "Associative Model of Data"
http://www.lazysoft.com/docs/whitepaper/AMD2.pdf does something similar
(although since he's not talking about XML specifically, so his
"associations" are not much like XPaths). 

Speaking of Simon Williams, his book (he'll send you a free copy if you ask
nicely)  has a quote I like: 

'Chris Date and Hugh Darwen in [The Third Manifesto book] simply take it as
axiomatic that we want to stay within the relational framework.  To them,
"it would be unthinkable to walk away from so many years of solid relational
research and development." No doubt typewriter manufacturers said something
similar.'

I may be digressing, but an implication of an XML DBMS support for efficient
storage/retrieval of well-formed XML is that you can get many benefits of
using a DBMS without going through the agonies of data modelling, database
design, and performance tuning that RDBMS-based applications traditionally
suffer. This seems to be one of the things that annoy the RDBMS purists the
most  -- see my buddy Fabian Pascal's obnoxious retort to a person from
NeoCore who pointed this out ...
http://www.firstsql.com/dbdebunk/neocore1.htm  ... and he doesn't like Simon
Williams much either http://www.firstsql.com/dbdebunk/amd1.htm .. nor me for
thaat matter ... [see his October Against the Grain ... the anonymous bozo
is moi].  The downside of this is that the application must do some
searching/sorting, manipulation and transformation that can be done in a
DBMS engine in a pure relational application, but again,my argument in this
thread in a nutshell is: XML DBMS often hit the "sweet spot" between
essentially doing everything -- even querying/transactions/backup/restore --
in applications code and doing all the extensive design, coding, and
administration a full-fledged RDBMS application takes.