ModSAX (SAX 1.1) Proposal

[David Megginson]

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
degree:

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("http://www.megginson.com/sax/handlers/ping")) {
        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

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)