ModSAX (SAX 1.1) Proposal

David Megginson david at
Tue Feb 23 18:53:23 GMT 1999

James Clark writes:

 > My point is it doesn't stop you doing:
 > public class PingHandler implements ModHandler { }
 > ModParser parser;
 > parser.setHandler("org.xml.sax.namespace", new PingHandler());
 > Declaring the second argument to be of type ModHandler doesn't ensure
 > that it is of the correct type.  It's not type-safe.

Precisely, and this is really the critical design decision for the
basic architecture of ModSAX.  To put the problem succinctly, we are
forced to trade-off type safety and flexibility/modularity to some

1. Using inheritance allows strict typing but breaks
   chain-of-reponsibility, since every driver has to know about every
   interface, and breaks maintainability, since everything has to fall 
   into a single inheritance tree.

2. Using runtime discovery (handlerID, etc.) breaks strict typing but
   allows chain-of-responsibility and greatly simplifies
   maintainability (we probably won't need another major SAX release
   when the schema group finishes datatyping, for example).

The arguments for both are good; my proposal is that we use an empty
interface (ModHandler) to allow at least *some* type checking, but
that we require the drivers to do some of the type-checking themselves
(or simply try to cast and let the exceptions bubble up).  This isn't
too big a burdon, since it falls on the drivers (few) rather than the
applications (many).  For example, here's how a typical filter might
deal with a handler (assuming a helper class ModFilterImpl):

  public class PingFilter extends ModFilterImpl
    public void setHandler (String handlerID, ModHandler handler)
      throws SAXNotSupportedException
      if (handlerId.equals("")) {
        this.handler = (PingHandler)handler;
      } else {
        getParentParser().setHandler(handlerID, handler);

The casting will throw a runtime exception if handler is not actually
of type PingHandler; a clever driver could trap that and do something
informative with it, but it is still not as good as catching the
problem at compile time; on the other hand, people will be able to
invent many new, interesting filters and drivers for SAX without
waiting for me to change the core distribution.

All the best,


David Megginson                 david at

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
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