events vs callbacks (was Re: SAX2 (was Re: DOM vs. SAX??? Nah. ))

[David Megginson]

Bill la Forge writes:

 > >Event-based programming existed before people started
 > >encapsulating events in structures or objects.  I'd define SAX as
 > >an event-based API that reports events using callbacks.
 > 
 > But why are we not taking advantage of having the events as
 > objects?  I've tried to second guess why this is so, but I think
 > the arguments in favor of object-based events is stronger: the
 > added overhead is balanced by greater simplicity and subsequently
 > less overhead in other areas; the added flexability adding
 > additional utility to all conformant code.

>From a design-pattern perspective, Bill is absolutely right:
encapsulation and abstraction are big winners, and the way that he
suggests is the proven method for building a robust system.

Rightly or wrongly, however, SAX 1.0 decided to err on the side of
simplicity and small size: while I agree that event objects could be
implemented to run nearly as fast as the current scheme (so close that
the difference would be negligible), there would have been other
hidden costs:

1. The byte-size of the SAX interface JAR itself would have been much
   larger, maybe twice or three times as large because of all the
   additional *.class files.  This may not seem to matter for most of
   the computing applications that are using SAX right now, but SAX is
   intended to be used eventually in low-bandwidth applications
   (i.e. over a wireless modem) and low-resource applications (i.e. on
   a palmtop), where every byte counts.  When a programmer is optimising
   for size, using XML at all is a hard sell if the XML parser adds
   25-500K to the application size; even though it's small, SAX adds
   even more, and I wanted to give it the best chance of slipping
   through.

2. Event objects greatly increase the initial learning curve, though
   they make it easier later on -- that's why so few people in the
   SGML world ever learned SP's (quite good) interfaces.  When we were
   designing SAX, we wanted to give it every chance we could -- it was
   not obvious at the time that SAX would be successful, so we had to
   make certain that coders without deep OO experience could learn it
   quickly, at a single glance, before they lost interest and moved on
   to something else.

3. Event objects greatly increase the burden of documentation --
   chapters on SAX in XML books would have to be much longer, since
   every event object would need its own section; likewise, people
   would have to do more clicking around in the JavaDoc pages (from
   DocumentHandler to StartElementEvent back to DocumentHandler to
   EndElementEvent back to DocumentHandler to CharactersEvent etc.).

In other words, SAX is a classic example of the worse-is-better
approach to software design, the kind that almost always wins, much to
the annoyance of people like me who really do like good design
patterns and robust, well-abstracted systems.  

In two or three years, I fully expect to see people (unknowingly)
using SAX on the next-generation of palmtops with wireless Internet
access, choosing a new sweater to buy from Eddie Bauer while they're
riding the bus back to campus -- at least, I hope to see that, as long 
as we're smart enough not to kill off SAX's original advantages in
round two.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

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/ and on CD-ROM/ISBN 981-02-3594-1
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)