[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Dennis Sosnoski" <dms@sosnoski.com>
To: "Karl Waclawek" <karl@waclawek.net>
Cc: <xml-dev@lists.xml.org>
Sent: Monday, March 08, 2004 2:37 AM
> >I think the problem is not initialization, but rather
> >"finalization) - i.e. cleanup. If a filter acquired
> >resources, then it would not release them until (if ever)
> >startDocument() is called again.
> >
> >
> >
> I understand, but it's possible to code around that for cases where this
> is really a concern. I find it more of an issue if a chain of filters
> doesn't reinitialize properly after an error termination, and
> initializing state on startDocument() at least takes care of that case.
Of course.
> As we've discussed, the alternative being considered is to *always* call
> endDocument(), even when the parse is being terminated by an exception.
> This seems counter-intuitive to me, and to at least some others on this
> list. If this method were called "parsingDone()" or something of the
> sort I wouldn't see it as a problem; it's the actual method name and the
> perceived similarity between startElement()/endElement() and
> startDocument()/endDocument() that makes it feel wrong to me.
Yes, sounds more reasonable, as from the "cleanup" point of view such
a method is the counterpiece to parse() rather than startDocument().
Maybe we need both, one focussing on the actual end of the document,
one indicating the end of the parsing process. And then one can
divide responsibilities in a more intuitive way.
> BTW, I think this is another example of how pull APIs offer a cleaner
> structure than push APIs. With a pull API you link filters by passing
> through calls to the next filter in the list. It's easy to use a try { }
> finally { } structure to handle exception terminations in this case.
Actually, IMO, filtering is the one application were the push model
appears more natural to me. Filtering through call-backs is a generally
useful approach, not just in SAX parsing. It allows you to separate the
processing (pull oriented) from the filtering more clearly.
I think that most pull parser might be push parsers internally,
just for the purpose of filtering/checking which nodes to skip.
You can also build a pull parser easily on top of a push parser as long
as the push parser can be suspended and resumed. Otherwise it gets
a little tricky, with multiple threads and such things.
In the SAX dot NET project we are actually adding the IXMLReaderControl
interface to make this possible.
Karl
|
