On Tue, Oct 24, 2006 at 04:00:48PM +0200, Jens Teubner wrote:

On Tue, Oct 24, 2006 at 03:40:16PM +0200, Ying Zhang wrote:

...

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?

This is a typing thing, and I've already implemented that. Whatever the expression after "at" evaluates to, we try to cast it into a string. This is in line with how XQuery is defined elsewhere.

You cannot express such a restriction in your grammar, though. This is a pure typing thing.

What is then the right definition of the grammar rule? XRPCCall ::= "execute" "at" "{" URILiteral "}" "{" FunctionCall "}" or XRPCCall ::= "execute" "at" "{" ExprSingle "}" "{" FunctionCall "}" (BTW, are the braces added correctly?)

...

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.

Done already. :-)

...

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.

I will have to think about how we can implement such a check most elegantly within Pathfinder. I'm wondering about its usefulness, though. I accept that we may want to restrict it to non-built-ins only. But is the import via a module a sensible restriction? i

I think it does make sense to filter out XRPC calls to in-query UDFs. If an in-query UDF is called with XRPC, the query just cannot be executed, since we don't want to ship the function implementation in XRPC request. So if such a query is not rejected by the compiler, it will eventually be rejected by the XRPC sender.

I could easily create some module with some function definition and import it. Still, the respective function would not be available at the XRPC target machine. I think we cannot really check whether a target machine will actually implement a given function (and if it does so with the same argument types). So we will have a garbage in, garbage out situation always. Does it then make sense to do this very special check at all?

Maybe we should put even more restriction on the imported module, such as we can require that the imported module should be available in a location which is accessible via the HTTP protocol. This way, we know it for sure that both the XRPC client and the server can access the module definition file (provided there is not further authentication restriction of accessing the file), and both the client and the server access the *same* module definition file, so the argument types should be the same (right?). Is it difficult to implement this restriction? Jennie

Jens

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

SQL0437W Performance of this complex query may be sub-optimal. Reason code: "3". SQLSTATE=01602 -- IBM DB2 V7.1 Warning Message