> 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@ccil.org 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)