* 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...