Cart
[Home] [By Thread] [By Date] [Recent Entries]
david@m... wrote: > This is much easier to handle with a SAX filter that implements both > Parser and DocumentHandler and buffers the character data. Which someone using my ParserFilter class can write in < 1 day. > In fact, a string of filters (Chain of Responsibility in > Design-Pattern-speak) can give users an awful lot of control for very > little work. You betcha. And because each filter component can specified by a Java system property, chaining can be done at run time very neatly. The highest level filter is specified as org.xml.sax.parser, and each lower level is specified by <successor class name>.parser, thus: -D org.xml.sax.parser=com.domain.chance -D com.domain.chance.parser=com.domain.evers -D com.domain.evers.parser=com.domain.tinker -D com.domain.tinker.parser=com.domain.SAXDriver sets up a chain where SAXDriver (the real parser) passes to tinker, which passes to evers, which passes to chance, :-) which passes to the application. Of course all this can be set up programmatically too. > All of this can be done above the parser/driver level, so > there's no need to complicate SAX by including it in the core spec > itself (except for including a canonical Filter interface). Absolutely. > Yes, but how do we accomplish this? Do we invent a new package name > for SAX 1.0.1 to avoid collision? I think that would be better than new class names. -- John Cowan http://www.ccil.org/~cowan cowan@c... You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) 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...)
|
