Lists Home |
Date Index |
- From: Paul Rabin <email@example.com>
- To: <firstname.lastname@example.org>
- Date: Fri, 22 Jan 1999 11:36:09 -0500
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:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)