[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XML versus Relational Database
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: Linda Grimaldi <firstname.lastname@example.org>,John Cowan <email@example.com>
- Date: Tue, 06 Feb 2001 13:31:32 -0600
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
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Linda Grimaldi [mailto:firstname.lastname@example.org]
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.