[Monetdb-developers] XRPC syntax

Ying Zhang Y.Zhang at cwi.nl
Fri Oct 27 12:39:57 CEST 2006


Hi Peter,

What is the reason that you want to avoid using the additional braces?

I found the formal definition of XQueryD grammar (BTW. it's called
XQueryD, not DXQ.  DXQ is something else.) in "A Framework for XML-Based
Integration":

  ExprSingle ::= "execute at" <URL> [ "xquery" { ExprSingle } | ... ]

So they also use braces to surrond the piece of xquery query that will
be executed remotely.  This is similar with '{FunctionCall}'.  And since
Jens said that using extrax braces will make parsing easier, so I
thought it won't hurt to have one more pair of braces to surround the
destination expression.


Jennie


On Tue, Oct 24, 2006 at 08:47:48PM +0200, p.a.boncz at chello.nl wrote:
> Hi Jens,
> 
> I had missed this email. The ambiguity you identify is for operators, which by default are built-ins. Thus, technically there is no ambiguity. 
> 
> In this case, you would parse "x eq y" as an ExprSingle, and then you will actually give a parse error because of the missing function application.
> 
> If it is really impossible to do (for some reason), I would propose the syntax:
> 
> XRPCCall ::= "execute" "at" ExprSingle "function" FunctionCall
> 
> which is analogous to DXQ: "execute" "at" ExprSingle "xquery" ExprSingle
> 
> Peter
> 
> 
> > 
> > van: Jens Teubner <jens.teubner at in.tum.de>
> > datum: 2006/10/24 Tue PM 02:55:21 MEST
> > aan: Ying Zhang <Y.Zhang at cwi.nl>,  P.Boncz at cwi.nl
> > onderwerp: XRPC syntax
> > 
> > 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.
> > 
> > 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.
> > 
> > ...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.
> > 
> 




More information about the developers-list mailing list