Lists Home |
Date Index |
Daniel Veillard writes:
> Personally I think SAX makes a terribly bad API for programmers,
> forcing then to work with callback, i.e. loosing the thread of
> control dusing parsing, and making hard to actually gather data
> from just an event stream. SAX is too low level for most use,
> through it certainly has its use as a lower API to implement the
> lower level services. But those layers are not where the typical
> programmer should meet the XML data.
I agree, for the most part. SAX is a terribly difficult way for
programmers to deal with XML, especially if they are already
struggling just to get their minds around XML itself.
The problem is that they often hit a point where they have no choice
-- what works fine in the small, proof-of-concept implementation
suddenly falls to pieces under real-world-scale load testing in a busy
server. That's why we see so many programmers posting to xml-dev
about SAX mid- to late-project, rather than at the during planning --
they've come to the point where learning SAX is less painful than
spending another month of late nights and weekends trying to figure
out some other way to make their server handle more than a couple of
hits per second.
In summary, then, SAX is the root canal of XML programming -- you try
less painful solutions first, but if nothing works, it's time to lie
back in the chair, close your eyes, and open wide, to avoid losing
your teeth altogether.
That aside, the other strength of SAX comes when you're going to be
building an in-memory tree anyway, but it does not happen to be a DOM
tree. Using the low-level events from SAX to build (say) a tree of
geographical coordinates is much more efficient than building a DOM
tree, then building a second tree of geographical coordinates from
that, then garbage-collecting the DOM tree. In that case, most
programmers in the project will never see SAX -- the load/save library
should hide it completely.
All the best,
David Megginson, firstname.lastname@example.org, http://www.megginson.com/