SAX: Next Round
rabin at shore.net
Fri Jan 22 16:41:39 GMT 1999
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.
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;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev