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

[PaulT <pault12@pacbell.net>]

----- Original Message -----
From: "Bob Hutchison" <hutch@xampl.com>

> 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).

I thunk that was not the developer's fault. In the absence of XPath
in DOM, every developer had to re-invent the XPath
wheel, because manual navigation in DOM three is masochistic.

I think that now, when DOM finally get's XPath, many people
will just use XPath and even novice developer could write
the code you're talking about so that it will be clean and tiny.

The code for the task you're talking about would be
something like :

event = root.GetByXPath ("/config/events/event[name = 'event_name']");
event_attribute = event.GetByXPath("./@attribute");

e t.c. XPath makes a *huge* difference. It is slow
sometimes terribly slow (perl/Python) , but that should not be
a problem for many applications.

> 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.

XML Data Binding rocks, but DOM + XPath can replace
it in many cases. DOM and XPath are still kinda fat, slow
and 'standalone' ( they're not native entities for many
of existing languages/tools, like 'Hashtable' is, for example )
but that's minor problems, I think. Should work fine for many applications.

> 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.

And you use SAX for what? I guess to write your application-specific
data binding.

Now consider, if you have DOM with XPath, would you bother
translating ( manually, with SAX )

<doc title="title">
<elements>
<e id='1'>value</e>
<e id='2'>value</e>
</elements>
</doc>

Into

class Doc {
    Array getElements();
    String getTitle()
}

so that

title = doc.getTitle();
elements = doc.getElements();

Or you'd just  do:

title = root.GetByXPath ("/doc/@title");
elements = root.GetByXPath("/doc/elements/*");

> I could go on...

Would you? I found your letter to be very reasonable
and pragmatic.

Rgds.Paul.