[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Storing Lots of Fiddly Bits (was Re: What is XML for?)
"Borden, Jonathan" wrote: > > > 3. Therefore we should pretend that relational databases are really DOM > > trees. > > no. if the data is tabular then use a recordset. in the specific cases when > 1) we are storing data which is naturally hierarchical. 2) when the data > needs to interface with systems which for other reasons employ DOM > interfaces Okay. We can probably all agree with this. If you have software that is expecting a DOM and you need to connect it to data that is not XML, you need to build a DOM interface. This is a different point of view from those who say: "let's build new client software using only the DOM served by data with only a DOM interface. The fact that the DOM is standardized will just make all of my interoperability problems go away." No way. If your client software and your server software had an impedence mismatch, slapping a DOM interface on both sides makes it *worse* not better. > e.g. my XSL processor us built on a DOM interface and I wish to > query the database using XQL (which happens to be built into my XSL > processor in this example), it is more convenient to interface to the data > using DOM interfaces than it is using recordsets (i.e. tabular data). It's more convenient but it's probably going to run as slow as hell. Nobody implements SQL or OQL on top of an industry-standard interface. They put it right in the core engine of their database. > Arguably, when using an ODBMS this example would be more straightforward > (but you picked RDBMS). The problem is that there is no standard, language > independent interface onto ODBMS's. ********** Yes there is! ************* It isn't as widely hyped as XML/DOM. I haven't written a book about it (and hardly has anyone else). But the standards *do* exist. Check http://www.odmg.org. There are well defined APIs, bindings in a few languages, a solid object model and a query language. It's all in there. My fear it that these technologies will get lost in the XML hype. > The DOM, while not the perfect interface > *is* standard, and this is the big utility. The DOM is a standard for accessing XML, HTML and CSS information. It isn't for modelling arbitrary business objects. It wasn't designed for that and it isn't good at that. > For example, I get to say (using 'extended DOM'): > > NodeList anotherSet = airplanes.selectNodes("airplane[@color='red' and > .//screw/thread/@pitch = 64]"); > > to select all red airplanes with screws having a pitch=64... The DOM is doing essentially nothing here. This imaginery XML query language is doing all of the work. But even the XML query language is going to make solving your problem harder than OQL would. For instance OQL can be statically type checked. XQL cannot, in general, for many subtle reasons. OQL can handle mathematical range constraints. OQL has a concept of a "stored query" that allows some level of abstraction. OQL has "local variables" also for abstraction. I don't completely follow your examples: > XMOP for example (http://jabr.ne.mediaone.net/documents/xmop.htm) is a way > to serialize arbitrary COM objects using their typeinfo metadata. XMOP is a > layer that can persist objects into either a) a stream (serialization) b) > direct-to-DOM. When I attempted to design a direct-to-Recordset persistence > interface on XMOP I found that I had to essentially develop a > DOM<->Relational mapping. This is because arbitrary objects can be modelled > in a hierarchical fashion (e.g. serialized to XML). This seems like a serialization problem. We all agree that XML is great for serialization. If your only goal was to get the data into a "database of some kind" then an OO database would have been easier than an XML database. > In another example, using the medical imaging DICOM protocol (a complex > property based protocol) I have developed a mapping to the Microsoft > PropertySet format (used with Index Server). This mapping is not clean (at > all given the inability to represent certain DICOM structures as > PROPVARIANTs). This causes similar problems in mapping the protocol to a > relational database (the workaround is to use binary data). Using XML and > the DOM was a piece of cake to solve this difficult problem. I'm not at all clear on how the DOM solved this impedence mismatch. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
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
|