[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Will XML eat the web?
"Matthew Sergeant (EML)" wrote: > > > You could continually update the DOMs based on changes in the XML. What > > exactly are your concerns about this architecture. > > > Not everyone (ourselves included) uses DOM. We started that way but > found it too resource intensive (large amounts of both processing and > memory). We switched to a simple expat parser and built our own query > language based on XQL paths. This gave a huge speed up and drop in resource > usages, but I still have concerns. I don't see how you can, in general, implement something like XQL without having random-access to the element tree. Anyhow, I don't care if you use the *DOM* in particular. It's a particular, poorly thought-out specification for the more general case of random-access tree structures. If you do need random access tree structures then you might as well store those structures persistently instead of regenerating them from source each time. Even if you only need stream-based access, there are much more efficient (time and space) encodings for a stream of XML text than XML itself. Of course if XML is the editable source then the encoded versions are merely optimized reflections, not definative archival source. > > You need to store data that is efficiently maintained relationally. You > > need to *transmit* XML. Why not use a relational database and create XML > > when you need it. > > > That's not always the best (or possible) solution either. I didn't claim it was. You cited a particular case where the data was naturally relational. I said: "then use a relational database." There is no universal architecture. You must choose the best one for your application. If the data is relational, store it in a relational database. > For > example we may ultimately allow people to edit the XML directly on the > server. If people want to edit it directly then the data is probably not naturally relational. Most people do not have a burning urge to load up a multi-megabyte file that looks like: <RECORD NAME="" ID="" STREET="" CITY="" PHONE_NUMBER=""> in "vi" or "emacs." On the other hand, if the data looks like a document that people want to edit, then it probably is not efficiently stored or served by a relational database (unless you apply some tricky levels of object orientation on top). That's a different situation and requires a different architecture. > Also, what gain would we then get from transmitting XML? You said that you wanted to be ready when XML became available on the client. I pointed out that when the time comes it is trivial to generate that data from a relational database. If your problem today is generating HTML from a rows and columns dataset and your question today is "how does XML fit in" my answer would be: "it probably does not." XML is cool but it doesn't fit every system. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html 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/ 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
|