ModSAX (SAX 1.1) Proposal

[David Megginson]

James Clark writes:

 > I don't see the point of this.  It doesn't seem to buy me anything over
 > what I can already do using normal programming language features:

 > interface PingParser extends Parser {
 >   void setPingHandler(PingHandler handler);
 > }

[snip]

Thank you very to to James for his comments.

James's suggestion complicates the the chain-of-responsibility pattern
for SAX programming, and that pattern has proven very productive in
SAX work so far.

For example, consider the following set-up:

1. the application is a client of
2. an attribute-inheritance filter, which is a client of
3. a ping filter, which is a client of
4. the XP ModSAX driver

Only #3 will implement the PingParser interface, so my application
will have to know to register its DocumentHandler with (2) but its
PingHandler with (3).  

Using the ModParser interface, the application could register both of
its handlers with (2), the top-level ModParser; (2) would accept the
DocumentHandler object directly (as it must), and would pass the
PingHandler along the chain to its parent filter; any ModHandlers that
made it to the XP ModSAX driver and were not recognised would cause a
SAXNotSupportedException.

 > The ModHandler class seems particularily useless.  It just creates
 > a completely unnecessary dependency between handler classes and the
 > SAX package.  You could use Object just as well.

This is admittedly a matter of taste, but empty interfaces are common
in the Java world as a statement of intent, and they do have the
advantage of slightly-stronger type checking.  I far prefer

  void setHandler (String handlerID, ModHandler handler)
    throws SAXNotSupportedException;

to

  void setHandler (String handlerID, Object handler)
    throws SAXNotSupportedException;

because stupid bugs are more likely to be caught at compilation time
rather than runtime, and that's always a win for creating robust code.

 > None of this seems to solve the real problem which is actually
 > defining the handlers that are needed to provide the functionality
 > missing from SAX 1.0 (like the handlers for comments, namespaces
 > etc that were in the previous draft).

This design provides the infrastructure for adding those handlers --
once we have a standard way of adding new handlers to SAX without
rewriting the interface, we can define some implementations of
ModHandler for lexical information, etc., exactly as in the previous
draft.  With this new infrastructure, we can also now specifically
request (non-)validation, (no) namespace processing, external entity
(non-)expansion, etc., and we can do capability discovery in a more
robust way.  A year or two from now, we won't need to issue SAX 1.2 to 
handle, say, data-typing.


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)