SAX: Next Round

[Lars Marius Garshol]

* Bill la Forge
|
| I think we are very very close, particular when you consider that
| DocumentHandler, DTDHandler, EntityResolver are the event receivers.

Well, I like my solution, but I'm not sure that it can be used. I'll
try to figure out the implications tomorrow.
 
| 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". 

Yup. This is what my proposal hinges on.

| 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.

Yup again.
 
| I do like your idea of having a seperate EventSource, which Parser
| and Filter both extend. 

So do I, but I'm pretty sure that means breaking binary backward
compatibility. Ie: if you try to use it with an old SAX parser or
application you'll probably get some dynamic linking-related error
from the JVM crashing your application. With a recompile it should be
OK.

We need to decide whether that's OK or not. Personally, I think it we
should say that it is, since the cost isn't that large and since the
cost of inflexibility in API evolution may well be huge in the long
term.

Oh, and for Python this isn't a problem at all, of course. :)

| 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.

Agreed.
 
| 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.
 
It should be easy to develop a simple FilterManager that retains that
benefit anyway, so I'm inclined to disregard that argument.

| So I really think the following is just great:
| 
| public interface Filter
|     implements Parser, DocumentHandler, DTDHandler, EntityResolver, 
|                ErrorHandler
|     public void setParser(Parser eventSource);
| }

Hmmm. This is uni-directionaly (handler -> parser) only, and also I'm
leery of making filter implement all the handlers. I'd rather keep
them separate.

| It means that in MDSAX we only need to change one interface and 4
| classes. Changes to ParserFilter can even be handled just by [...]

I don't mean to sounds dismissive, but I think it's so important to
get SAX 2.0 right that the implications for MDSAX and ParserFilter
should IMHO be completely disregarded.

Anyway, that's it for today for me. I'm now off to the pub. :)

--Lars M.


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)