[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX: Next Round
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|