Next Round

david at david at
Thu Jan 21 21:13:13 GMT 1999

Bill la Forge writes:

 > I've always thought using the Parser interface for filters was a
 > bit heavy weight.  I wanted to keep filters very light so that the
 > cost of doing things like namespace and bunches of other things
 > would be no greater than having them done inside the parser, and
 > yet give you a lot more configurability.

If there's a common helper class that people can use as a base, then
filters can be very light anyway (the base class should just pass
through all events unmodified and provide access to registered
handlers).  Here's a filter that renames all "foo" elements to

import org.xml.sax.AttributeList;
import org.xml.sax2.helpers.SAXFilter;

public class FooFilter extends SAXFilter

  public void startElement (String name, AttributeList atts)
    if (name.equals("foo")) {
      getDocumentHandler().startElement("bar", atts);
    } else {
      getDocumentHandler().startElement(name, atts);

  public void endElement (String name)
    if (name.equals("foo")) {
    } else {

 > I also didn't think a lot of folks would be filtering DTD events,
 > that is unless they got extended.

If people are using DTD events at all, they'll probably want to filter 
them (fiddling with notations, etc.).  Likewise with lexical events.

All the best,


David Megginson                 david at

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