SAX: Next Round

david at david at
Fri Jan 22 21:42:56 GMT 1999

Paul Rabin writes:

 > A number of contributors to this discussion are interested in using
 > SAX as a general interface for assembling XML-processing
 > components.  The extension of parser+application to a chain of
 > filters is an important first step, but only supports components
 > with at most one event stream input and at most one event stream
 > output.

Not really -- all you need is one specialised filter for splitting an
event stream.

 > What SAX extensions would be needed to support multiple event
 > stream inputs and outputs?  Filters that route events to one or
 > more event stream outputs have been implemented.  What is the best
 > way to register the handlers for multiple event stream outputs?

The Java-beans-ish way would be to have

  public void addDocumentHandler(DocumentHandler handler);
  public removeDocumentHandler(DocumentHandler handler);

 > Support for multiple event stream inputs raises control flow issues.  One
 > solution is to have a new version of parse() that returns immediately after
 > initializing the parse context, but without generating any events, and a
 > new getNextEvent() method that causes a single call to the appropriate
 > upstream handler to be made before returning.

I don't want to deal with synchronization issues at the SAX layer --
the idea is that SAX provides the raw information for higher layers to 
work with.  As long as SAX gives you the basic information about an
XML document, you can build a rich superstructure for more complex

All the best,


David Megginson                 david at

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list