OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] SAX/Java Proposed Changes

[ Lists Home | Date Index | Thread Index ]

Karl Waclawek wrote:

>>As for filters and handlers, they should always initialize their state 
>>on startDocument(). That will prevent any errors due to reuse after 
>>attempting to parse a bad document.
>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.

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.

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.

  - Dennis


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS