SAX2: pull interface

David Megginson david at
Tue Jan 18 14:35:05 GMT 2000

[questions at bottom]

There are two different ways that an event-based interface can work:
the event supplier can push events out to the consumer, or the
consumer can pull events from the supplier.

SAX is very much a push interface, but some people have asked if it
might be possible to add optional support for pull, so that you can do
something like

  Event e = xmlReader.nextEvent();

followed by a giant switch statement.

I don't want to do that, but here's a possible compromise:

1. Define an optional 'pull-events' feature.

2. Add a new method to XMLReader:

   public boolean nextEvent () 
     throws SAXException, IOException;

Here's how it would work: when the 'pull-events' feature is true, the
XMLReader parse() methods return immediately; after that, each
invocation of nextEvent() causes an event (or small cluster of events) 
to be sent to the registered handlers and then returns true.  Once
there are no remaining events (i.e. the document is completely
parsed), nextEvent() returns false.

If the XML driver doesn't support pull, or if it hasn't been activated 
with the 'pull-events' feature, then any call to nextEvent() could
either return null or throw a SAXNotSupportedException.


1. Is this adequate for the people who want pull?  I really don't want 
   to define a separate object for each event type (especially when we 
   allow arbitrary extension handlers).

2. Is it OK that a single call to nextEvent() might generate two or
   three events in some cases?

3. Would any of the parser writers out there want to support this?

I will take silence as an indication of a lack of interest.

Thanks, and all the best,


David Megginson                 david at

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.

More information about the Xml-dev mailing list