SAX: Next Round

[Bill la Forge]

I just realized something significant about the difference between John Cowan's 
filters and MDSAX.

MDSAX builds its filters from leaf to root, where the leaves of the filter tree
are the final destinations of the transformed events. The root filter is registered with
the parser. Events then travel from root filter to a particular leaf, the route depending
on the document type and possibly the element type as well. (DocumentRouter and
ElementRouter being filters which handle this routing.)

John's filter works in reverse, building layer upon layer of filter/parser, 
with events flowing up the stack from the first filter put on the stack to the last.

MDSAX does have an interface which extends Parser: MDContext. An instance of MDContext
could serve as a filter in a stack of filter/parsers, while putting a filter/parser in the MDSAX
filter tree would be a bit more challenging.

The conclusion, then, is that the less SAX says about filters, the better.

Guess I get to eat my own words now. Could you pass the salt? 

Bill


>I'm  sold!
>
>MDSAX filters will implement Parser!
>
[cut]
>
>With this, I remove all objections to having seperate event handler interfaces!
>
>Thanks all!
>
>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/
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)