[
Lists Home |
Date Index |
Thread Index
]
* Petr Cimprich <petr@gingerall.cz> [2005-01-17 10:33]:
> Alan Gutierrez wrote:
>
> >Thinking more in terms of pattern matching, less in terms of
> > document traversal.
> >
> >
>
> I have no problem with this kind of thinking (as far as I can see myself
> :). Any streaming processing is more declarative and there is not much
> space for a document traversal. But still, you have to maintain some
> amount of information to be able to decide if a pattern matches or not.
> > <xp:capture name="foo" select="/document/reverse"/>
> > <xp:insert-after match="/document/reverse">
> > <reversed><xp:value-of select="util::reverse($foo)"/></reversed>
> > </xp:insert-after>
> When you process endElement for reverse, you need to know whether its
> parent is document in order to decide if /document/reverse matches. This
> information necessary for matching is what I call "the context".
> Then, you could navigate through the context data with a XPattern-like
> language (with limited axis etc.), but this is another story. So, I'm
> also talking about matching patterns against a stream of events; but I
> just need to know what info is available to test the pattern.
To match that partuclar end element, with that partucular
pattern, you only need to update a state machine as the events
stream by. There's no need to traverse at end element. The
pattern matches and an event handler takes over the stream.
<foo>
<bar>one</bar>
<baz>
<a><b><c>two</c></b></a>
</baz>
<bar>three</bar>
</foo>
/foo[baz/a/b/c = 'two']/bar[. = 'three']
I can know that the above pattern matches at the end of the last
bar, without keeping any nodes at all.
--
Alan Gutierrez - alan@engrm.com
|
