[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Elliotte Rusty Harold" <elharo@metalab.unc.edu>
To: "Karl Waclawek" <karl@waclawek.net>
Cc: <xml-dev@lists.xml.org>; <sax-devel@lists.sourceforge.net>
Sent: Saturday, February 28, 2004 6:35 AM
> At 11:38 PM -0500 2/27/04, Karl Waclawek wrote:
>
> >I thought of the reverse direction.
> >How would a filter *down* the chain deal with an "end of parsing"
> >if it doesn't know why parsing stopped. Was it the end of the document?
> >Was there an exception? I think someone else pointed that out already,
> >but I missed the name.
>
>
> I'm not sure I see your problem. The parse() method either returns or
> throws an exception. If it returns normally, the end of document was
> seen. If it throws an exception it wasn't.
Actually, I was thinking rather in terms of a chain of
ContentHandlers, not true XMLFilter implementations.
I didn't make that clear.
Sometimes you don't know where the end of the chain is, so
you can't call parse() on it and you have to drive the
chain from the parser end.
You are obviously right with your argument for XMLFilters.
> Of course the filter only really nows what the previous filter in the
> chain tells it. It doesn't know and doesn't need to know what filters
> earlier in the chain say. That's the point of filtering.
Yes, as above, I was not clear at all.
The problem I described only arises when driving the
"contentHandler-filter" chain from the parser end, in
which case the filters down the chain have no parse()
call to evaluate.
Karl
|
