Cart
[Home] [By Thread] [By Date] [Recent Entries]
* 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...
|
