Cart
[Home] [By Thread] [By Date] [Recent Entries]
* Jeff Rafter <lists@j...> [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
>
>
> <foo>
> <bar1>
> <baz1/>
> <baz2/>
> </bar1>
> <bar2>
> <baz1>
> <sub/>
> </baz1>
> <baz2>text</baz2>
> </bar2>
> </foo>
>
> So when the event stream reached /foo/bar2/baz2/text() you would have
> the following in a DOM like structure:
>
> foo
> \
> bar1 (... no children)
> bar2
> \
> 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 - alan@e...
|
