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 ]

----- 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: Monday, March 08, 2004 9:22 AM

> >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.
> The problem with this approach is that it's unwieldy, not impossible 
> but not pretty. In this pattern, the data structures must be 
> initialized in one class before calling parse, filled in in the 
> ContentHandler during the parse, and then torn down or flushed after 
> the parse in the first class. 

It can all be done in the class that implements ContentHandler,
only the calls are coming from different places.
But it is more overhead, I agree. However, if we want to combine
initialization/finalization with the document boundary events, then
we run into the conceptual confusions this thread has demonstrated.

> Being able to rely on 
> startDocument()/endDocument() in the ContentHandler allows all the 
> initialization  and tear-down code to easily go in the same class as 
> the code that fills the data structure. It's all neatly unified. 

Why could it not go in the same class in the other case?

> This 
> doesn't necessarily do anything that the other pattern can't do. It's 
> just cleaner and easier to follow by keeping all the related code in 
> one place.

See above. Forcing endDocument() from a lexical point of view is wrong,
from a cleanup point of view is right (if it is the only event one can use).



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

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