|
|
|||
5.5.1 XRPC SyntaxRemote function applications take the XQuery syntax: execute at { Expr } { FunApp(ParamList) } where Expr is an XQuery expression that specified the URI of the peer on which the function FunApp is to be executed. For a precise syntax definition, we show the rules of the XQuery 1.0 grammar that were changed: PrimaryExpr ::= ... | FunctionCall | XRPCCall | ...XRPCCall
::= "execute at" "{" ExprSing "}" "{" FunctionCall "}" FunctionCall ::= QName "(" (ExprSingle("," ExprSingle)*)? ")" We restrict the function application FunApp to user-defined functions that are defined in a module. Thus, the defining parameters of an XRPC call are: (i) a module URI, (ii) a function name, and (iii) the actual parameters (passed by value). The module URI is the one bound to the namespace identifier in the function application. The module URI must be supplemented by a so-called at-hint, which also is a URI. The current choice to allow functions defined in XQuery modules is due to efficiency and security reasons. MonetDB/XQuery has the mechanism of caching the query plan of a module. For all subsequent use of the functions in a cached module, only the function parameters need to be extracted to be feed directly into the query plan. For security reason, by allowing only modules, it is trivial to specify which modules are allowed to be executed or not. It is important to know that actual parameters of the called function are passed by value (in contrary to by reference), which implies that if an XML node is passed as a parameter of an XRPC call, only its sub-tree is serialized in the request message and sent to the remote site. At the other side, the node will have a different identity; namely the one tied to the XRPC SOAP message (which also can be considered a document). |
||||
| © 1994-2011 CWI | Contact us Legal HG web Bugs TestWeb | |||