Re: [xml-dev] DOM or SAX: Sense and Sensibility

[Bob Hutchison <hutch@xampl.com>]

This is a serious issue. Here are a few thoughts... I'm not promising
anything more than that :-)

I've found that SAX is anything but obvious to the programmers I've worked
with, even programmers with extensive GUI experience (people who have
actually built a GUI framework don't have any problem). And even after being
pointed to SAX they don't always have much of an idea of how to proceed.
This isn't entirely their fault. We have nice frameworks for dealing with
events generated by GUIs. With SAX there is no such thing, that I'm aware
of. The developer is faced with a stream of events and no framework for
dealing with them. Yes, I know that you can quickly put something together
but I've been doing that for years, not every one has.

What's the consequence of getting it wrong? Serious trouble. You end up with
slow, ugly, unmaintainable code. Worse, I've seen developers using the
resultant mess to avoid using XML altogether (we really are still in the
early days of XML). A little, real-life, example... Consider an XML based
specification of some events and their response (not SAX events, but
application events). The code that interprets the XML file was using a DOM
representation, and it wasn't great code -- someone's first attempt at using
the DOM wound up in the product (that's another issue). What happened? It
was felt that the amount of code, and the obscurity of that code, makes XML
unsuitable and unsafe for this task, this task being 'application
configuration'. The question of how this should have been done never was
asked. The end result was replacing the nice little human readable XML file
with a complex database, with something like nine tables, that is maddening
in its difficulty to set up and impossible to for a human being to
understand. Worse, every other configuration file was also moved out of XML
into the database. Yes, there was politics involved, but still...

The system I was working on has a different issue: neither SAX nor DOM is
quite right. You want an in-memory representation of a collection of
'documents' but the DOM is too 'distant' -- the DOM is about the document,
we needed something else. I wound up writing an XML data binding (didn't
know it was called that then :-) This was *really* easy to get all the
developers in my group (about 17) using this.

As a matter of interest, recently I've use the pull-parser XPP. I have a
suspicion that this reversal of control flow will make it easier for a lot
of people to work with event based processing. Personally, I think I still
prefer SAX.

I could go on...

Cheers,
Bob


On 01/11/07 12:23 PM, "Bullard, Claude L (Len)" <clbullar@ingr.com> wrote:

> A topic for the usual Friday introspection two
> days early:
> 
> How often do you as experienced XML developers
> find people in your shop using DOM for work
> more appropriate to SAX?   Have you asked
> them why and what do they say?  What are the
> costs of picking the wrong API?
> 
> len