SAX Future

John Cowan cowan at
Fri Nov 13 16:17:26 GMT 1998

david at 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).

> 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		cowan at
	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 at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list