Hi Jens, First of all, thanks for your help! On Tue, Oct 24, 2006 at 02:55:21PM +0200, Jens Teubner wrote:

Hi Jennie, hi Peter,

I am currently looking into the XRPC syntax. Primarily I wanted to give you feedback to what you wrote in your Plan-X submission.

So you are defining the syntax to be

XRPCCall ::= "execute" "at" URILiteral FunctionCall

Lateron, however, you allow more than just a literal URI, but rather an XQuery expression. So `URILiteral' is definitely wrong here.

Our intention is to allow an XQuery expression here (after "at"), but it should be evaluated to a URILiteral. How can I correct this rule to express our intention?

Once you changed this to, say, ExprSingle, you end up with ambiguity in your parser. Consider

execute at "foo" eq ("bar")

(I couldn't think of a better example ad hoc.) What we have here is an ambiguity: we don't know whether `eq' is supposed to be a function call, or if it is the binary operator `eq', followed by another expression in parenthesis.

So I will take the freedom to modify your syntax proposal and do it in a more XQuery-like style:

"execute" "at" "{" Expr "}" "{" FunctionCall "}"

This avoids the ambiguity and should make it rather easy to parse.

With or without '{' and '}' doesn't matter for me:) So, if the braces make it easier for parsing, we should then just adjust the syntax definition. I'd like to mention that we need to check that the called function belongs to an imported module, thus it should not be a built-in function or a UDF which is in-line with the query. Regards, Jennie

...already hacking...

Jens

-- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263

Time is money. Especially if you make clocks.