Lists Home |
Date Index |
* Jeff Rafter <firstname.lastname@example.org> [2004-12-23 13:43]:
> >While on the topic of SAX taming features in Amara, there is also
> >amara.saxtools.xpattern_sax_state_machine, which I didn't even bother
> >mentioning in the announcement (too much to cram in).
> Can you expand on your expansion? As I was reading this I was thinking
> that in the Java/C# world an interesting approach would be to keep a
> pseudo DOM stack for the event hierarchy. Maybe something where you keep
> everything at an ancestral level intact while parsing
> So when the event stream reached /foo/bar2/baz2/text() you would have
> the following in a DOM like structure:
> bar1 (... no children)
> baz1 (... no children, just the previous sibling and attrs)
> baz2 (only the StartTag)
> I am not sure that the preceding siblings would be very useful and have
> more chances for pathological cases but when I construct mini-trees this
> is the subset I find handy. It is useful when working with an editor to
> understand the immediate context. Unfortunately by requiring the
> previous siblings you have to maintain quite a bit more... the whole
> preceding branch of the tree.
I have a SAX library (in Java) that keeps the stack around, but
not the preceeding siblings. It is quite useful.
It is, actually, very useful to keep a stack around that has a
hash table for each level of the stack, it allows for the
devleopment of strategies that are themselves stateless.
Adding the implied stack goes a long way to make SAX event
processing a more practical solution for a lot of problems.
Alan Gutierrez - email@example.com