ModSAX (SAX 1.1) Proposal

[David Megginson]

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

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

Here's how I register it with a ModParser:

  try {
    parser.setHandler("com.megginson.handlers.ping", 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("com.megginson.handlers.ping")) {
      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
exception.

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
SAXNotSupportedException.


 > 	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

-- 
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)