Cart
[Home] [By Thread] [By Date] [Recent Entries]
From: David Brownell <db@e...> >I've always liked the idea of filters in the SAX event chain. >As Bill la Forge (and you) noted, that's a fine way to address that >general issue. One can overdo layers, of course, and pay for it >in performance. But filters are a good architectural notion, and >there's been lots of discussion about how to use them well with >SAX and DOM. > >That does imply keeping DOM out of the basic parser API, which >I still think is the best way to go. An event generator (say, >a SAX parser, or something walking a DOM tree) can have its >events filtered, and delivered to acomponent building a DOM tree. A filter can itself hold a stack of other filters, or even a set of filters to which events are routed based on some pattern. Being able to place just one filter in front of the DOM built by the parser is all you really need. Using the ModParser interface, can do the following: 1. Use setFeature to turn on DOM construction. 2. Use set to insert a filter in front of the DOM. 3. Parse a document. 4. Use get to retrieve the constructed DOM. Bill 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/ and on CD-ROM/ISBN 981-02-3594-1 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...)
|
