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

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

-----Original Message-----
From: Soumitra Sengupta, Ph.D. [mailto:soumitra@b-bop.com]
Sent: Wednesday, October 17, 2001 11:18 AM
To: Magick, Brian
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] XML Database Decision Tree?


> In the third paragraph of his response he correctly points out the issue
of 
> "referential integrity" that Native XML DBMS
> does not support.  

My point is XML *itself* has no conception of referential integrity; the
problem doesn't go away by storing it in an XML-enabled RDBMS of some sort.
Disagree?

Solving the problem via RDBMS technology would seem to require documenting
the mapping of XML onto the internal RDBMS representation in a way that XML
users could exploit, e.g., to cause entity references to be re-expanded
after the content of an external entity changes.  That's the kind of thing
that RDBMS triggers do, and I can imagine how an XML DBMS built on RDBMS
technology could exploit it ... but it's not obvious to me. Furthermore,
this could require the end-user to understand the internal storage
architecture, and data independence (to steal an RDBMS term) is the whole
*point* of a native XML DBMS, as I see it.  And once you start talking about
triggers, this is not part of the relational model, just implementation
technology that "proprietary database technology" could do just as easily as
an RDBMS.  What am I missing here?

> I will let the representatives of Software AG and Excelon explain under
what 
> circumstances their solution will provide you with value.

As Leigh reminds us, XML-DEV is more suited for discussions of XML
*technologies* than XML *products*, so I'll spare the rest of you ... anyone
who wishes to discuss this offline is free to contact me.

But this discussion of referential integrity reminds me of another point I
forgot to make in my response: 

If you WANT your XML representation to change when an underlying information
item changes (e.g., the customer address in a purchase order should change
when the address in the customer database changes), RDBMS-based solutions of
one sort or another are generally more appropriate.  If you want the XML
representation to reflect a snapshot of reality (e.g., the XML purchase
order is a "contract" that is digitally signed for purposes of
non-repudiation), and you don't want the XML representation to change
(breaking the digital signature!) when the underlying data changes, a native
XML DBMS are generally more appropriate.

<digression>
This makes me think that XML (itself, NOT native XML DBMS!) has a different
default conception of "integrity" than the relational model.  The relational
model describes individual axioms about reality, and an RDBMS query can
essentially prove all sorts of theorems about how they relate to each other.
(I believe the metaphor is C.J Date's). "Integrity" means maintaining the
consistency of the axioms. XML "documents" on the other hand (and I use the
term advisedly) combine specific sets of inter-related axioms describing
some specific domain (contract as signed, opinion as of today, documentation
of the product as of version 3.2.1 or whatever). XML queries "prove" much
more limited sets of assertions (because basically only hierarchical "is a"
/ "part of" / etc. relationships can be modelled this way), thus are
optimized for one specific, but very class of problems.  XML "integrity"
then, refers to maintaining the relationships within the hierarchy of
assertions, not between those assertions and external reality.

Anyway,the RDBMS fundamentalists think this idea is stupid, but whatever ...
</digression>