Lists Home |
Date Index |
- From: Lars Marius Garshol <firstname.lastname@example.org>
- To: "XML Developers' List" <email@example.com>
- Date: 22 Jan 1999 16:48:58 +0100
* 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
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.
| 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
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
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.
| 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,
| 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
| 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. :)
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)