RE: XML versus Relational Database

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

So what you are saying is, might be done 
but may not be worth the cost of doing 
it that way?  I agree.  I've read elsewhere 
from reasonable folks that DAD suffers at 
the hands of MOM.

I'm not convinced that some of the 
promises made for XML were realistic 
in terms of open generality.  Perhaps 
some drill down into your requirements 
may be useful to the thread although I 
may be able to guess some of them.
  
<rant>Many lessons of SGML applications 
were lost along the way.  Early works 
on squashing SGML docs into relational 
dbs were not totally successful.  It was 
like taking a dress catalog, slicing it 
into uneven sizes, putting these 
into a blender, then trying to find 
the price of blue bits in the goo. 
IOW, the navigation was terrible and 
dimensions of addressing had to be 
handled with meta tables.  Awkward.</rant>

The solution was advanced contentindexing 
that enabled one to JIT rebuild the 
catalog using the content relationships 
(thus the car analogy) and it only worked 
well if the cross-reference indexes were 'native' for 
example, reference designator systems 
in mil manuals.  Imposing these externally 
or at run time made the interface foreign.  
We had to design them into the database 
almost as business objects.

On the other hand, the total object systems 
suffered because the meta-property sets were 
not layered cleanly.  Thus, groves.  

If I am gleaning anything from the 
experience with the application language 
I mentioned in the earlier email, it is 
that the property set (a la groves) is 
about as good as it gets when one uses 
data declarations to support interoperable 
objects via shared standards.  

The object model itself, realized 
as an API, isn't enough. The cost of 
using the meta-API is performance.  So 
binding directly to an object model 
based on the named properties of the 
content becomes the alternative.  The 
tradeoff is flexibility.  From 
DOM to Applet and back again.  No free 
ride; no size fits all.

Ok.  I retract what I said. It isn't 
trivial if you account for efficiency 
and clarity of application.  It is a 
PIA to map a document to a relational 
database. 

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Linda Grimaldi [mailto:grimlinda@earthlink.net]

I guess my concerns are somewhat different.  What I want is a repository
that does not constrain my XML data and still gives me full access to all of
it in a meaningful fashion.  I'm kind of fed up with reading about "data
centric" vs "document centric" XML. I thought part of the promise of XML was
that I would eventually be able to handle documents as data and vice versa-
the distinction would be moot.

I want to design XML that works for my application, without having to worry
about making it fit into a relational database.