xml-dev - RE: SAX2: Handler Interfaces

["Box, Don" <dbox@develop.com>]

Title: RE: SAX2: Handler Interfaces

> -----Original Message-----
> From: David Megginson [mailto:david@megginson.com]
> Sent: Tuesday, March 14, 2000 5:45 PM
> To: 'xml-dev@xml.org'
> Subject: SAX2: Handler Interfaces
>
>
> Box, Don writes:
>
>  > 0) I think that the independence of ContentHandler, LexicalHandler,
>  > DTDHandler and ErrorHandler are carried a bit too far. In general,
>  > I would like to be able to ask the content handler for the lexical
>  > handler interface (a la Java's cast operator or COM's
>  > QueryInterface). To allow two distinct objects to be used, I would
>  > bake in the getter method instead of relying on the underlying type
>  > system.
>
> I have often worried about the same thing, but there are a
> few reasons
> for the approach:
>
> 1. In Java, it's not possible to use multiple class inheritance, so a
>    class that needs to inherit from something else (say, HashMap)
>    cannot also inherit from HandlerBase (SAX1) or DefaultHandler
>    (SAX2); that means that many implementors have to implement *every*
>    method in the interface. 

I wasn't advocating folding the methods of all four interfaces into a single "mega-interface". Rather, I was advocating a change to the way an XMLReader implementation acquires the "auxiliary" interfaces once it gets a content handler.

> My own assumption in SAX1 was that many
>    people would need to implement DocumentHandler, but that very few
>    would be interested in DTDHandler, so it was an unfair burden to
>    make everyone implement all of the callback methods.

I don't think I made myself clear. I wasn't advocating a change to any of the XXXHandler interfaces nor to DefaultHandler. Rather, I was questioning why XMLReader needs a separate "setter" for both ContentHandler and LexicalHandler (and arguably DTDHandler and EntityResolver). The only reason to use separate "setters" is to allow someone to use a separate object per interface. However, it is hard to imagine someone calling setLexicalHandler without also calling setContentHandler. Similar (but somewhat less compelling) arguments could be made for DTDHandler and EntityResolver.

Imagine an implementation of XMLReader that looked like this:

class MyReader implements XMLReader {
  ContentHandler ch;
  DTDHandler     dh;
  EntityResolver er;
  LexicalHandler lh;

  public void setHandler(ContentHandler h) {
    dh = null;
    er = null;
    lh = null;
    ch = h;
    if (h instanceof DTDHandler)
      dh = (DTDHandler)h;
    if (h instanceof LexicalHandler)
      lh = (LexicalHandler)h;
    if (h instanceof EntityResolver)
      er = (EntityResolver)h;
  }
}

If you don't like the casts (which are a cornerstone of interface-based programming in Java, COM and CORBA), one could add a specific "getter" method to content handler:

  public abstract Object getHandler(String interfaceName);

which would change the method above to look like this:

  public void setHandler(ContentHandler h) {
    ch = h;
    dh = (DTDHandler)h.getHandler("org.xml.sax.DTDHandler");
    lh = (LexicalHandler)h.getHandler("org.xml.sax.LexicalHandler");
    er = (EntityResolver)h.getHandler("org.xml.sax.EntityResolver");
  }

One of my main motivations for proposing this change is that I would like to see the role of XMLReader reduced. Ideally, passing around a ContentHandler reference should allow me to have sufficient information to "transmit" an entire XML Document. The way SAX2 sits now, I must pass around an XMLReader in order to give you a way to "discover" the four required interfaces. THis also means I'm passing around an object reference with methods like "setXXXHandler" and "parse", neither of which make sence.

In summary, my request is that we refactor in order to have a single object reference from which I can discover all four handler/resolver interfaces.

> 2. In SAX2, LexicalHandler and DeclHandler are not required
> interfaces
>    -- that is, implementations are free not to support them -- and I
>    expect that among those who do use them, LexicalHandler will be
>    much more heavily used than DeclHandler, so again, it makes sense
>    to separate them.
>
> In Java, it's no problem for a single application class to implement
> all of the interfaces -- I've been very careful to avoid method-name
> collisions.  In COM, are you required to use a separate class to
> implement each interface? 

No. Java and COM are pretty much identical in this respect. Provided you avoid methodname collisions, we are fine. FWIW, COM is just a style of C++ programming, not some major MS technology.

DB
http://www.develop.com/dbox