RE: XML versus Relational Database
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@i...] Sent: Monday, February 05, 2001 12:00 PM To: John Cowan Cc: xml-dev@l... 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@r...] 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.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format