[
Lists Home |
Date Index |
Thread Index
]
* Petr Cimprich <petr@gingerall.cz> [2005-01-17 11:18]:
> Alan Gutierrez wrote:
>
> >
> >
> > 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.
> I see. This way could be inconvenient if you have a lot of patterns and
> you don't know which of them will be tested in the beginning. Keeping
> some info for later evaluation or updating the state machine are
> different implementation approaches, XPattern should work for both.
> Anyway, I see why you refuse starting with context definition. Let's
> work with EBNF then.
> BTW, I think XPattern should be a subset of XSLT pattern
> (http://www.w3.org/TR/xslt20/#NT-Pattern) rather than XPath expression.
Refuse? I don't mean to come across as obstinate. I've been up
all night. Perhaps my tone is not what I would want it to be.
As far as handling content, I'm not thinking in terms of
fetching a nodes out of a tree, but in terms of capturing, and
responding to event with event handlers.
That's why I think there are two phases, defining the pattern
matching langauge, and then, as a second step, trying to come up
with a generic expression of capturing and replacing, or
inserting. The former is useful as on its own, for XML event
handling frameworks.
That said, I think that most of XSLT pattern can be matched,
by the time all the particpants have passed in the event stream,
by a state machine. (It's hard for me to imagine how you would
match joins, maybe run two machines to a meeting point? No, need
to have axis and literals, only.) I'm sure many of the axis can
be preserved.
--
Alan Gutierrez - alan@engrm.com
|