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

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

 >Paul T
 >If the process of dismantling / re-assembling is really fast and 
 >robust ( no parts would get lost ), the advantage is that you can 
 >park 10-1000 times more cars in the same space.  And perhaps 
 >have more trees in downtown as a side effect.

I'd be very interested in seeing a realistic example of how this theoretical
advantage could work.  Of course if cars could be stored in RDBMS, you could
store each type of screw, nut, bolt, bearing, etc. just once and save
storage... but you'd also have to store all the relationship information to
specify where all those parts go.  In "native" XML, those "part-of"
relationships are implied by the containment hierarchy. If the redundant
content had much more information than the description of where it went, you
could get the space advantage, but you would have awfully boring documents! 

Of course, if there is a LOT of redundant information in an XML document
(e.g., boilerplate text), XML has XInclude, embeded XLinks, external
entities to address this common problem.  What native XML (in or out of a
database) doesn't have is a good discipline for referential integrity
between the entities and references; indeed the InfoSet and XPath data model
doesn't expose the fact that all the bits of boilerplate came from a single
source.  I'll freely admit that if the boilerplate is changing and you want
to query on the contents of the boilerplate (e.g., find all the documents
that include an XInclude'd policy document containing the string "irradiate
all mail"), the RDBMS solution is superior to the (nonexistent?) native XML
solution.