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

[Jeff Greif <jgreif@alumni.princeton.edu>]

Some forms of intra-document referential integrity could be in the form of
idrefs required to match ids.  Perhaps xlink could be used to provide some
inter-document referential integrity, and I suppose some fragment - fragment
referential integrity within a document.  I wonder if the Schematron engine
could be adapted to check other kinds of constraints, even between
documents.

Clearly people can implement contracts management in RDBMS, storing the
(digitally signed) text as a CLOB, and shredding into elements suitable for
relational storage.  If the customer address has to be preserved against
changes for the sake of the contract, then you would store addresses in an
address-history table.  (And all those elementary SQL examples where you
give everyone a 10% raise should not update a salary in the employee record,
but insert in a salary-history table.)

Jeff
----- Original Message -----
From: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
To: <xml-dev@lists.xml.org>
Sent: Wednesday, October 17, 2001 11:34 AM
Subject: RE: [xml-dev] XML Database Decision Tree?


...
> 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?
>
...
> 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.
>