ModSAX (SAX 1.1) Proposal

David Megginson david at
Wed Feb 17 15:52:30 GMT 1999

Ingargiola, Tito writes:

 > Why is interface ModHandler empty?  Presumably, (an implementation
 > of) ModParser is going to need to call methods on its handlers as
 > it goes about its business .  Will it somehow know that for
 > ModHandlers which implement, say, namespace processing, that it
 > should call a particular method (I won't even attempt to suggest
 > what that method might be :-)?

Maybe it will help if I walk through a silly example.  Here's the

  public interface PingHandler extends org.xml.sax.ModHandler
    public abstract void ping ();

Here's how I register it with a ModParser:

  try {
    parser.setHandler("", pingHandler;
  } catch (SAXException e) {
    System.err.println("Parser does not support Ping handlers");

Here's part of my PingParser class:

  private PingHandler pingHandler;

  public void setHandler (String handlerID, ModHandler handler)
    throws SAXNotSupportedException
    if (handlerID.equals("")) {
      pingHandler = (PingHandler)handler;
    } else {
      throw new SAXNotSupportedException("Unknown handler type: " 
                                         + handlerID);

In other words, if the class recognises the handlerID, then it will
know how to cast it; if it does not, then it should throw an

The ideal design pattern for this is the Chain of Responsibility
pattern, where we have a series of filters between the application and 
the actual XML parser, all of which support the ModParser interface;
if a filter does not recognise a handler type, it can pass it back to
its parent, and only the root parser actually throws a

 > 	In java, empty "marker" interfaces appear:
 > 		1) for pieces of "silent" functionality like Cloneable and
 > Serializable where a standard interface simply doesn't apply, or 
 > 		2) where the variety of types of applications which will
 > need to have a formalized contract with some piece of functionality is so
 > broad that it is prohibitvely difficult to define the appropriate method
 > signatures for that interface; extended interfaces are expected to
 > proliferate (e.g., EventListener & friends).
 > 	It seems to me that SAX is clearly not a case of 1), and while it
 > may be a 2), it isn't obviously so.  

It looks to me like it hits both quite nicely.

 > 	I'm afraid that ModHandler's current (suggested) definition is
 > too open-ended -- it may encourage interoperability problems.  The
 > key virtue (in my opinion) of SAX is that it allows me to plug an
 > arbitrary parser into the front of my XML processor and I'm nearly
 > guaranteed that if it's IBM's or J. Clark's or whomever's, it's
 > going to work.  A marker interface inside the parser seems to me to
 > threaten this happy state of affairs...

Not really -- you're guaranteed the same level of interoperability as
before (because the full SAX 1.0 Parser interface is still there), but 
now there is a standard, layer-able method for adding new handler
types and for determining whether they're supported or not.  People
have been expanding SAX anyone, and I just want to provide a nice,
clean method for doing so.

If I had something like

  public interface ModHandler
    public abstract void event (String eventID, Object eventArgs[])
      throws SAXException;

then I'd put the burdon of casting onto the application (many times)
rather than the parser (once).

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