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?

> -----Original Message-----
> From: Jeff Greif [mailto:jgreif@alumni.princeton.edu]
> Sent: Wednesday, October 17, 2001 8:15 PM
> To: Champion, Mike; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] XML Database Decision Tree?
> Perhaps xlink could be used to 
> provide some inter-document referential integrity, and I suppose some 
> fragment - fragment referential integrity within a document. 

Sure, it's just that the details  really haven't been worked out HOW to do
this, the XLink spec isn't widely implemented in real DBMS systems, and the
formal relationship between XLink-based "business rules" and those
implemented in RDBMS systems has not been elucidated by the theorists
(AFAIK).  XQuery takes a stab at this (they have a JOIN operation that could
presumably be implemented with XLink in an XMLDBMS and some flavor of
relational join in an RDBMS), but again the two worlds speak different
languages, and it's not clear a) when to use one vs the other and b) how you
make them work together.  I think your suggestions are interesting and
should be research fodder in academia ... but I'm not sure if native XML
DMBS are on their radar.

> Clearly people can implement contracts management in RDBMS, 
> storing the (digitally signed) text as a CLOB, and shredding into 
> elements suitable for relational storage. 

Sure, you can write *applications* that do this, but ideally redundancy
elimination and referential integrity are services that a *DBMS* can provide
more efficiently, reliably, recoverably, etc.  Designers have to make
tradeoffs between "building" functionality in an application vs "buying"
services from a DBMS, between the infinite flexibility of the relational
model and the "optimized for the usual case" convenience of the XML model,
etc.  This thread is meant to identify some of these tradeoffs and propose
heuristics ("decision trees") for addressing them, as I see it.