SAX: Next Round

[Paul Rabin]

David, et al,

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.

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?  Should extended versions of
setDocumentHandler(), etc., take an additional index parameter?

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'd appreciate hearing about experiences with these or other approaches to
improving the connectivity of SAX-based XML processing components.

	Paul Rabin
	JXML



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