[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX and parallel processing
* Uche Ogbuji <Uche.Ogbuji@f...> [2005-01-01 15:33]: > On Fri, 2004-12-31 at 16:37 -0800, Bob Foster wrote: > > Right. In order to process a SAX stream in parallel you have to copy the > > data in the stream, you can't just "forward" the events. You also have > > to instantiate a context for each event, including at least the > > namespaces in scope, the Location info. I didn't mean to imply this > > would be excessively expensive, just not as lightweight as serially > > processed SAX. > > Maybe this is where my perspective, so surprising to so many here, comes > from. In Python SAX, all event objects are dissociated from the driver. > > I must say I think it somewhat vindicates the Python approach that it so > easily extends the framework to advanced implementation strategies. > > I had forgotten this about the original SAX, and I must say it makes for > a lot more of an "assembler-level" view than SAX as I'm used to using > it. In SAX Strategy, the events are assicated with the driver, more or less, until a need for an immutable copy of the data arrises. As I noted, before about Characters, also Attributes, a resuable object is used, and Characters indexes into the parse buffer, but if you need to keep a copy it's like. Characters characters = (Characters) event.getCharacters() .getImmutable(); Or a more generic. Lexeme lexeme = event.getLexeme().getImmutable(); SAX raw is basically an API for connecting handlers. A few more gew-gaws, and the obverer/event pattern is much easier to impelment. -- Alan Gutierrez - alan@e...
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|