[
Lists Home |
Date Index |
Thread Index
]
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):
public interface IXmlHandler<S> where S: EventStatus
{
void Reset();
void ProcessingInstruction(string target, string data, S status);
void SkippedEntity(string name, S status);
}
public interface IDocHandler<S>: IXmlHandler<S> where S: EventStatus
{
void StartDocument(object context, S status);
void EndDocument(S status);
void StartRoot(QName name, IAttributes attributes, S status);
void EndRoot(S status);
}
public interface IElementHandler<C, N, S>: IXmlHandler<S>
where C: XmlPathContext<C, N, S>
where N: XmlPathNode<N, C, S>
where S: EventStatus
{
// context is valid until Deactivate is called, but attributes is only
// valid during the call to Activate
void Activate(C context, QName name, IAttributes attributes, S status);
void Characters(char[] chars, int start, int length, S status);
void IgnorableWhitespace(char[] ws, int start, int length, S status);
// called before child is activated
void StartChild(QName name, IAttributes attributes, S status);
// called after child is deactivated
void EndChild(S status);
void Deactivate(S status);
}
> 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?
Karl
|
