[
Lists Home |
Date Index |
Thread Index
]
* Karl Waclawek <karl@waclawek.net> [2005-01-17 10:23]:
> Alan Gutierrez wrote:
> >* Karl Waclawek <karl@waclawek.net> [2005-01-17 09:16]:
> >
> >
> >>> 4. Position counters (to enable position predicates and
> >>> position()
> >>
> >>>function)
> >>
> >>Especially for a streaming processor, should the goal of a pattern
> >>matching language not be, to allow for flexible cooperation
> >>between what the language does and what the handlers do?
> >
> >
> > Brings me back to my suggestion for a generic XPath binding API.
> >
> > public interface Function {
> > public Node invoke(NodeList arguments);
> > }
> >
> > Works for Java.
> >
> > What works across all languages?
>
> If one "language" needs to interact with multiple other
> languages, then what we are talking about is multiple
> "lanuage bindings".
>
> >>Predicate evaluation could also be performed in the handler
> >>call-backs. So, maybe the XPattern language could provide for
> >>simple attribute value matching, but leave more difficult tasks to
> >>the call-back handlers, which can take advantage of a Turing
> >>complete language, and which can also easliy interact with
> >>application context (e.g if our database has a record for this
> >>id, return true, otherwise return false). And there should be a
> >>specified way for how the handlers return results for predicate
> >>evaluation.
> >
> >
> > I'm of that mind set. I like this proposal.
> >
> > I'd like to match information, then respond with Java. My
> > example, simplified.
> >
> > <document>
> > <reverse>Alan</reverse>
> > </dcoument>
> >
> > Transformed to:
> >
> > <document>
> > <reverse>Alan</reverse>
> > <reversed>nalA</reversed>
> > </document>
>
> I am using an API I have developed mostly for myself
> (although open sourced). Whenever I match an element,
> call-backs are made on one of these interfaces (C# with generics):
[snip]
> > I'm looking to notified of a reverse element, and to be notified
> > of the end of the reverse element, so I can insert the reversed
> > element. This isn't really node matching, but event matching.
> >
> > + = open, - = close, () = capture, [] = emit
> >
> > +document
> > +reverse (foo) -reverse
> > [+reversed &util::reverse($foo) -reversed]
>
> Some events for the API above would be (matching on /document/reverse):
> - Activate(..., "reverse",...)
> - one or more Characters() calls
> - Deactivate(...)
> In the Deactivate event the handler would emit:
> <reverse>Alan</reverse>
> <reversed>nalA</reversed>
> The handler wouldbe derived from an existing helper class, which
> performs character buffering.
> For that task that would be all the pattern matching language and
> API support I would need. Maybe there is a danger of overengineering
> in this discussion?
No. I don't think so. There pattern matching component ought to
exist as it's own specification, apart from applications within
a C# framework, or STX like language.
My immediate application would be similiar to yours, matching
point in the stream, and evoking SAX like handlers.
This notion, of replacement, substitution, or insertion after,
could also be done using a XUpdate/STX language, however. I'm
putting it out there as an example application.
--
Alan Gutierrez - alan@engrm.com
|
