SAX: Next Round

[Bill la Forge]

I think weare very very close, particular when you consider that 
DocumentHandler, DTDHandler, EntityResolver are the event receivers.

Now remember that, so far as event passing goes, MDSAX and ParserFilter
work the same. Its only in wiring them up that they are "particular". All we really
need is to loosen the wiring requirements. In both cases, this means little more than
providing a null constructor and subsequent set methods.

I do like your idea of having a seperate EventSource, which Parser and Filter both extend.
For when you have a tree of filters, it seems silly to call parse on one of the leaves, especially
if the leaf is particular to an element type.

On the other hand, I can see arguments for just using Parser. For
simple filter stacks, it makes things real easy and I like that.

So I really think the following is just great:

public interface Filter
    implements Parser, DocumentHandler, DTDHandler, EntityResolver, ErrorHandler
{
    public void setParser(Parser eventSource);
}

It means that in MDSAX we only need to change one interface and 4 classes. Changes to 
ParserFilter can even be handled just by subclassing existing implementations, since John was 
careful to use protected on the parser variable and will accept a null value in the constructor!

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)