ModSAX: Core Proposal for Filters

[Bill la Forge]

It would be strange for ModSAX not to accommodate filters. Frankly
I've been wondering if we really need a separate filter interface and
for SAX the answer was no. But for ModSAX, I would argue that
we need a filter interface.

One key issue here, one of the few that can not be addressed by ModSAX
as it stands for filters, is the routing of the get/set/setHandler/setFeature
events. (Lets call these application events, since that is the direction they
come from.)

In a simple filter stack, it is easy enough to route these events down towards
the parser, allowing them to be intercepted by any intervening filter on the way.
(Interception is one possibility here, but it handles nicely the problem of
recognizing that the event has been processed.) But when the structure
contains an event router (for parser events), things fall apart.

Event routers let you do things like process parser events differently for different
types of elements or different types of documents. But for application events, you
may need to chain all the subordinate filters together. Unfortunately even this
doesn't work if the application event is needed by more than one filter. It also
becomes quite slow if there are a large number of different kinds of elements and
consequently a large number of filters subordinate to an event router.

The JavaBeans approach seems to be best. Provide for application event registration,
and allow more than one Parser to be registered for the same application event.
This combined with a default behavior of passing application events towards the 
parser should work nicely.

Also, because a filter may have a whole raft of properties specific to itself, it will be
helpful to provide for a very crude form of wildcarding. We can easily constrain such
properties to all have the form: common ID, '#', property sub-id. Registration of the
common ID should be sufficient to allow the routing of all such application events.

The interface is

public interface ModFilter extends ModParser
{
    public abstract void register(String ID, ModParser parser)
        throws SAXNotSupportedException;
}

Now, will a ModFilter also need to extend DocumentHandler,
ErrorHandler, DTDHandler, and EntityResolver? Strictly speaking,
these are implementation issues, so the answer should be NO.

Time for a quick recap of application event processing by filters:

1. If a filter doesn't know what to do with an application event, it
    passes the event towards the parser (to the next filter on the
    stack, or to the parser if it is the last filter on the stack). Any raised
    exception is passed back toward the application.

2. A filter may contain any number of other filters or filter containers.
    The assemblage of such a structure can also support registration,
    a la JavaBean event registration. Any number of filters may be
    registered with another filter to receive specific application events,
    depending on the event ID.

3. A filter may have its own unique ID, assigned or hard-coded (that's
    an implementation issue). It can also have a number of properties
    useful for configuring that specific filter, each with its own unique
    subID. Such properties can be accessed using a propertyID of the
    form filterID#propertySubID.

4. Application events with partitioned property IDs will be routed when
    the filterID has been registered.

(The first production release of MDSAX 1.0 is due out "real soon now".
But frankly, I can't wait to use the ModSAX interfaces. They will be the
corner stone for the 2.0 release, I'm sure. ModSAX is going to let us
simplify a lot of the interfaces.)

Bill


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)