RE: XML versus Relational Database

[Linda Grimaldi <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.  I have spent a couple of
days now trying to fit a perfectly valid, reasonable XML structure into an
"XML-based" aggregator's relational schema.  I am not happy.  It looks like
there may even be features of my data, critical from a business perspective,
that their schema can't support.  My current XML doc and application support
it just fine.  Some of this I can attribute to poor RDBMS design, but not
all.  Most of it I attribute to the idea that "one size fits all" can really
work.  You mentioned in an earlier email that we can do a pretty good job
with custom solutions, but it's expensive.  I would argue that we therefore
do a crummy job with custom solutions, and that it is possible to develop
methodologies that use XML, a true XML repository, and assorted
template-based transformation tools (XSLT yes, but maybe some other
possibilities as well) and get "mass customization" (yuck- I hate that term)
a lot more cheaply.

Linda


-----Original Message-----
From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
Sent: Monday, February 05, 2001 12:00 PM
To: John Cowan
Cc: xml-dev@lists.xml.org
Subject: RE: XML versus Relational Database


Understood and while I like to have choices,
I am watching one fairly important language
effort derail because early in the development
cycle, they chose to specify multiple bindings
without really separating the syntax away from the
abstract property definitions.  Multiple
encodings are madness without that.  As a
result, it is unlikely they will be able
to write a spec to govern all of the
quickly emerging and competitive language
variants.  XML is no help here; it is a
competitor which divides some and rallies
other, but ultimately, as the Grovesters
discovered, markup is inadequate for
for standardization of systems if adequate
for specifications of syntax-centric vocabularies.

And so, of course, the prose is normative
and the choice of means open to interpretation,
thus, interoperability is elusive.

Linda's question could be answered with a
laundry list, and perhaps that is what she
wants.  I'd say that on top of that list,
DOM support is item number 1.

What do you think of this article?

http://www.scottandrew.com/index.php/articles/dom_doit

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

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

From: John Cowan [mailto:jcowan@reutershealth.com]

The features all XML systems (i.e. processors)
*must* support is very restrictive, and doesn't
at present even include GIs or element nesting.

*Should* support, well, who knows?  That's why
the Infoset doesn't pretend to be normative;
it's a library of names of features thought to
be generally useful.