Will XML eat the web?

[Paul Prescod]

"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 at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)