OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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

----- 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
> 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
> 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
> triggers, this is not part of the relational model, just implementation
> technology that "proprietary database technology" could do just as easily
> an RDBMS.  What am I missing here?
> If you WANT your XML representation to change when an underlying
> item changes (e.g., the customer address in a purchase order should change
> when the address in the customer database changes), RDBMS-based solutions
> 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
> XML DBMS are generally more appropriate.