developers-list October 2006

developers-list@monetdb.org

16 participants
47 discussions

[Monetdb-developers] configure & *_config.h include files

by Stefan Manegold

Dear fellow developers, while trying to fix portability issues with the pftijah modules of pathfinder, I noticed the following problem: To ensure portability, each source file should know about and adhere to what configure found out; hence, the respective X_config.h (with X one of monetdb, sql, pf, etc,) must be the first include in each .c file. However, with the front-ends, some files (especially those implementing extension modules) also need to MonetDB's monet.h or gdk.h to get the respective definition. Since monet.h includes gdk.h which includes monet_utils.h which in turn includes monetdb_config.h, these files the include both the "local" X_config.h (with X one of sql, pf, etc,) and the monetdb_config.h. This might trigger two problems: 1) If we compile sql, pf, etc, a against a binary install of MonetDB which was configured and generated on an binary compatible but potentially (slightly) differently configured/installed system, this might lead to conflicting definition/declarations in the two X_config.h. 2) Even if we compile MonetDB and the front-end on the same system, there might be conflicts since the respective configure are not completely identical. In pathfinder/runtime we avoid (2) be not including pf_config.h but only monetdb_config.h (via monet.h or gdk.h) which might actually lead to problems similar to (1). In pathfinder/module/pftijah, we run into (2) with _FILE_OFFSET_BITS (at least) on our Solaris 10 x86 machine, since only MonetDB' configure.ag checks AC_SYS_LARGEFILE() while pathfinder's configure.ag does not. To solve the problem (2) "properly", we could either make all configures identical (e.g., by moving all "local" checks from the various configure.ag to MonetDB/conf.monet.m4). But that still leaves us with (1). To solve (1) (and (2)) "properly", we could avoid the implicit inclusion of monetdb_config.h in monet_utils.h (and hence gdk.h & monet.h) by removing the respective include from monet_utils.h. But then, we'd have to explicitly include monetdb_config.h in each .c file that now includes one of monet_utils.h, gdk.h, monet.h (directly or via some other include) --- a lot of work, with a high risk to overlook some locations... A "better"(?) (at least simpler) solution could be to guard the #include "monetdb_config.h" in MonetDB' monet_utils.h by, say, #ifndef NO_MONETDB_CONFIG ... #endif, and then define NO_MONETDB_CONFIG in X_config.h (with X one of sql, pf, etc,). I'd strongly vote for the last solution. ;-) Comments, ideas, complaints, objections? Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

15 years, 7 months

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/compiler/core coreopt.brg, 1.35, 1.36 fs.brg, 1.43, 1.44

by Stefan Manegold

On Tue, Oct 31, 2006 at 09:28:29AM +0000, Jan Rittinger wrote: > Update of /cvsroot/monetdb/pathfinder/compiler/core > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv27557/core > > Modified Files: > coreopt.brg fs.brg > Log Message: > -- Aligned typing of the rule 'locpath (StepExpr, StepExpr)' (StepExpr may > e.g., be a step with an predicate) with the specification. Instead of > a typeswitch that casts all sequences of nodes into node* before applying > distinct-doc-order we now introduce a function > '#pf:distinct-doc-order-or-atomic-sequence'. It can handle the typing > without loosing the more specific type and will be replaced in the core > optimization either by a distinct-doc-order (in case of a node sequence) > or the input of the function (in case of an atomic sequence). > > (This should also solve Stefans typing problems.) yes, it does! (just like it fixed the same problem as reported in bug #1586454 "XQ: treat as") Thanks, Jan! Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

15 years, 9 months

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/tests/W3C_use_cases/XQUF/R/Tests Q7x.milS, 1.2, 1.3 Q7x.stable.out, 1.2, 1.3

by Jan Rittinger

Stefan, your rewrite may return different results (at least without schema knowledge). If you have E1/E2[P] the predicate P is evaluated on E2 only. Your rewrite changes the binding to E1/E2 and is thus equivalent to (E1/E2)[P]. The correct rewrite thus would be doc("items.xml")/items/item_tuple[itemno=1002] -> doc(\"items.xml\")/items/(for $i in item_tuple where $i/itemno=1002 return $i) which would result in the same translation as without the for loop. On 10/30/2006 10:09 PM, Stefan Manegold wrote with possible deletions: > Update of /cvsroot/monetdb/pathfinder/tests/W3C_use_cases/XQUF/R/Tests > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv14959/XQUF/R/Tests > > Modified Files: > Q7x.milS Q7x.stable.out > Log Message: > > with a path expression E and a predicate P, > Pathfinder's derives the type of > E[P] > as "node", while this could be "element" as required by some functions; > replacing > E[P] > by > for $i in E where P return $i > yields an "element". > > Added althernative versions for all tests where E[P] triggers a type error > but for $i in E where P return $i works fine. > > > Index: Q7x.stable.out > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/tests/W3C_use_cases/XQUF/R/Tests/Q7x.stable.out,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -d -r1.2 -r1.3 > --- Q7x.stable.out 30 Oct 2006 20:54:19 -0000 1.2 > +++ Q7x.stable.out 30 Oct 2006 21:09:18 -0000 1.3 > @@ -15,7 +15,7 @@ > xquery("xml"," > do insert > <comment>This is a bargain !</comment> > -as last into exactly-one(doc(\"items.xml\")/items/item_tuple[itemno=1002]) > +as last into exactly-one(for $i in doc(\"items.xml\")/items/item_tuple where $i/itemno=1002 return $i) > ").printf(); > > xquery("xml","doc(\"items.xml\")").printf(); > > Index: Q7x.milS > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/tests/W3C_use_cases/XQUF/R/Tests/Q7x.milS,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -d -r1.2 -r1.3 > --- Q7x.milS 30 Oct 2006 20:54:19 -0000 1.2 > +++ Q7x.milS 30 Oct 2006 21:09:17 -0000 1.3 > @@ -4,7 +4,7 @@ > xquery("xml"," > do insert > <comment>This is a bargain !</comment> > -as last into exactly-one(doc(\"items.xml\")/items/item_tuple[itemno=1002]) > +as last into exactly-one(for $i in doc(\"items.xml\")/items/item_tuple where $i/itemno=1002 return $i) > ").printf(); > > xquery("xml","doc(\"items.xml\")").printf(); > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins > -- Jan Rittinger Database Systems Technische Universität München (Germany) http://www-db.in.tum.de/~rittinge/

15 years, 9 months

[Monetdb-developers] starting a new user...

by Romulo Goncalves

Dear developers, I created a user, schema and I set the new schema for the new user: CREATE SCHEMA "test" AUTHORIZATION "public"; CREATE USER "monet_test" WITH PASSWORD 'pass_test' NAME 'TEST USER' SCHEMA "sys"; ALTER USER "monet_test" SET SCHEMA "test"; Then I connect the new user with a mclient: [goncalve@amelia Dependencies]$ mclient -umonet_test -Ppass_test MAPI = monet_test@localhost:50000 ACTION= mapi_start_talking ERROR = !InvalidCredentialsException:checkCredentials:Invalid credentials for user 'monet_test' [goncalve@amelia Dependencies]$ What is the problem with the user creation? The authorization for the schema is public this means that any user can use the schema "test". I am right or wrong? I will appreciate some help. Best Regards, Romulo Goncalves

15 years, 9 months

[Monetdb-developers] 'at'-hint URI for XRPC calls

by Ying Zhang

Hello Jens, An XRPC call needs to know the value of the 'at'-hint of its module, so that it can tell the XRPC receiver where to load the module file. The implementation of the previous XRPC syntax (import rpc-module) saves the 'at'-hint in 'apply.rpc_uri'. In the implementation of the current XRPC syntax (execute at...), this information is gone. I'm wondering if the struct PFfun_t or one of its member can be extended to include the value of the 'at'-hint. Regards, Jennie

15 years, 9 months

[Monetdb-developers] XRPC Syntax

by Peter Boncz

Dear all, I know you don't probably want to see any more emails on this, but I will re- visit the proposed XRPC syntax once more. The following proposals have been made: (a) "execute at" SimpleExrp FunctionCall (in the paper) (b) "execute at" "{" SimpleExpr "}" "{" FunctionCall "}" (currently implemented) (c) "execute at" "{" SimpleExpr "}" FunctionCall (lighter variant) (d) "execute at" SimpleExpr "xquery" FunctionCall (XQueryD.1) (e) "execute at" SimpleExpr "function" FunctionCall (XQueryD.2) I will first try to summarize the positions on these proposals: - Jens: stresses the point that lexical analysis should be easy. Secondary, he values a connection with XQueryD, with preference for full query support (not only module function calls). Jens supports (b), (c) and (d). - Jennie: seems not to care about the exact syntax. Tis may be a ery wise position. - Torsten: prefers parentheses notation, to denote a lexical scope with special semantics (similar to element and attribute). Supports (b) and (c). - Peter: is rapidly progressing to a point not to care, but under interrogation will still confess to a preference for (a). Is this an interrogation?? Yes, yes, I will confess: As XQueryD is "dead" in the sense that it is not even in Galax where it was proposed, I do not feel inclined to adapt all of the syntax necessarily (we do adopt "execute at" in any case, so they can be happy with that). The XQueryD proposal requires quite a bit of analysis and transformation to correctly parse a query with some variables appearing without being defined, in the free-form xqueries they support. This is not required when viewing an RPC as a remote *function* call, such that the XQuery language support for function signatures can be leveraged to make parameters explicit. Then, for the user the simplest syntax for RPC is (a), at least in the sense that it is the shortest. Suppose we *do* view XRPC as an extension of XQueryD (I actually don't), or really a special case within it, as Jens says. Because free-format xqueries need extra implementation effort (parameter extraction) and a protocol extension (to send the query definition), and cannot benefit from pre- processing and a function cache (easily) we can and want to use a faster execution strategy for the specific (XRC) case of module function calls (i.e. optimized to fit into the function cache -- this saves a lot of latency, from 170msec to 35msec) . To aid this decision, syntax support can be given (i.e. using the keyword "function" instead of "xquery"). Also, with two different keywords, systems could support both functions and free-form, or any of the two. Therefore, if asked for my preference after (a), I would favor (e) over (d). But once again, I actually do not feel much about the need to be XQueryD consistent. Now Torsten's opinion is that when it is necessary to delimit the thing being RPC-ed, then parentheses may be the most logical delimiters. This then goes counter to the XQueryD proposal, which uses "xquery". His well-formulated argument then made me start doubting my second-best preference (e); maybe (b) is after all more logical. Still, it does not make me doubt about my first preference, (a). \Is explicit delimiting necessary, for an extension that does not build on XQueryD, and only has the ambition to call single XQuery functions remotely, in any case? I'd say no. What remain are Jens' reserves about (a) being possible/attractive in the scanner/parser. I can come up with the below short diff. Unless previous versions, this one works, and abides to the spirit of the scanner that refrains from using input()/unput() nor REJECT. When in operator mode, the scanner should not see a QName followed by a parenthesis, unless it is a builtin operator name (e.g. "x" eq ("y")), so QName- s were not allowed. In case of XRPC style (a), this is what happens when finishing the parse of the URI expression( e.g. execute at "x" fcn("y")). My modification addes a rule with lowest preference in the OPERATOR mode to accept a QName (lowest pref, so it was not recognized as a builtin operator), and then matches the '(' in a new more EXPRFCNCALL mode that serves just that purpose. Peter Index: scanner.l =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/scanner.l,v retrieving revision 1.40 diff -r1.40 scanner.l 136a137 > || YY_START == EXPRFCNCALL \ 343a345 > /* 25 EXPRFCNCALL */ 368a371 > %x EXPRFCNCALL 607,608c610,611 < "execute"{_}"at"{_}?"{" { pushState (OPERATOR); pushState (DEFAULT); < yield (execute_at_lbrace); } --- > "execute"{_}"at"{_}? { pushState (OPERATOR); pushState (DEFAULT); > yield (execute_at); } 776a780,787 > {QName} { gotoState (EXPRFCNCALL); > pflval.qname = extract_qname (yytext, 0); } > . { yield (invalid_character); } > } > > <EXPRFCNCALL>{ > {_}?"("/[^:] { gotoState (DEFAULT); > yield (QName_LParen); } Index: parser.y =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/parser.y,v retrieving revision 1.47 diff -r1.47 parser.y 353c353 < %token execute_at_lbrace "execute at {" --- > %token execute_at "execute at" 2766,2767c2766,2767 < XRPCCall : "execute at {" Expr "}" "{" FunctionCall "}" < { $$ = wire2 (p_xrpc, @$, $2, $5); } --- > XRPCCall : "execute at" Expr FunctionCall > { $$ = wire2 (p_xrpc, @$, $2, $3); }

15 years, 9 months

Re: [Monetdb-developers] New serialize form of XRPC message

by Jan Rittinger

Hi Jennie, Your output looks pretty good. I would reuse as much as possible from the xml-typed mode. If you however have conflicts then I'd introduce new callbacks. In your case it seems sensible to introduce all the namespace declarations in some xrpc_serializeStart event that also prints the whole envelope tag. A xrpc_serializeStop event may then close this element. In addition you would need a new xrpc_seqStart and xrpc_seqEnd callback that uses a user-given sequence name and does not generate the namespace declarations. As you can see I proposed to introduce two new callbacks that have to be placed before/after the loop over the different iterations -- That change would be fine with me. It however requires to introduce dummy routines that have to be called for all modes except xrpc (the serializeFunStruct and its instances have to be modified -- see serialize*.mx and modules/...). What do the other think? Jan On 10/23/2006 05:32 PM, Ying Zhang wrote with possible deletions: > Hello Jan, > > With this e-mail, I would like to ask for your advice how I can > reuse/adjust the current serialization code of the "typed" mode to > support serializing the new XRPC response message. > > Maybe you have seen in our (Peter and I) XRPC paper for PLAN-X that we > have defined an XML schema for the XRPC request and response messages. > The schema definition file is avaible here: > http://monetdb.cwi.nl/XQuery/XRPC.xsd > > An XRPC response message now looks like this: > > <?xml version="1.0" encoding="utf-8"?> > <env:Envelope > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:env="http://www.w3.org/2003/05/soap-envelope" > xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope" > xmlns:xrpc="http://monetdb.cwi.nl/XQuery" > xsi:schemaLocation="http://monetdb.cwi.nl/XQuery http://monetdb.cwi.nl/XQuery/XRPC.xsd"> > <env:Body> > <xrpc:response xrpc:module="xrpcmodule" xrpc:method="test"> > > <xrpc:sequence> > <xrpc:document><a/></xrpc:document> > <xrpc:element><a/></xrpc:element> > </xrpc:sequence> > <xrpc:sequence> > <xrpc:attribute x="y"/> > <xrpc:text>z</xrpc:text> > </xrpc:sequence> > <xrpc:sequence> > <xrpc:processing-instruction>z</xrpc:processing-instruction> > <xrpc:comment></xrpc:comment> > <xrpc:atomic-value xsi:type="xs:integer">1</xrpc:atomic-value> > <xrpc:atomic-value xsi:type="xs:decimal">42.100000</xrpc:atomic-value> > <xrpc:atomic-value xsi:type="xs:string">bla</xrpc:atomic-value> > </xrpc:sequence> > > </xrpc:response> > </env:Body> > </env:Envelope> > > As you can see, the new form of XRPC response message is quite different > than the current form of the XRPC messages, but it is very similar to > the way the result of an xquery is serialized in the "typed" mode. > During the making of the new schema, we have actually consulted the > output of the "typed" mode to use the same type names, so that we can > reuse as much as possbile the code of the "typed" mode. > > The "xrpc:sequence" part is very similar to the "result:sequence" part > of the typed mode. In serialize_dflt.mx, the seriializeFunStruct-s of > "xml typed" and "xml soap" only differ in the following: > > struct serializeFunStruct struct serializeFunStruct > typed_xmlSerializeFun = { typed_xmlSerializeFun = { > "xml typed", "soap xml", > > typed_xml_seqStart, xml_seqStart, > null_complete_seqStart, xml_complete_seqStart, > typed_xml_seqEnd, xml_seqEnd, > typed_xml_seqItemStart, soap_xml_seqItemStart, > typed_xml_seqItemEnd, soap_xml_seqItemEnd, > null_seqItemSeparator soap_xml_seqItemSeparator > }; }; > > If we make two changes in the typed_* functions, all xml_* and soap_* > functions in "soap xml" can by replaced by the typed_* functions to > procude the new XRPC response messages. With these changes, we can even > get rid of the "soap" mode, and just use the "typed" mode to serialize > XRPC response messages. > > The changes I would need are the following: > > (i) instead of using the static prefix "result", use a dynamically > specified prefix, so that i.s.o. "result:sequence", "xrpc:sequence" can > be printed for XRPC response messages. Can we store the prefix in the > existing parameter XqueryCtx* ctx? Or do we need to add a new parameter > to the typed_* functions? > > This change is not _strictly_ necessary, since I can also use the prefix > "result" in the XRPC response messages, but using dynamically specified > prefixes looks nicer/cleaner to me. > > (ii) for XRPC response messages, I'd prefer to not have the namespace > definitions of "result" (or "xrpc"), "xs" and "xsi" in > <result:sequence>, because each XRPC response message can contain a > (large) number of sequences. With the NS definitions of "result", "xs" > and "xsi" included in every sequence tag is obviously wasting of > bandwidth. Do you have an idea how this change can be implemented > nicely? > > > I hope I have made my problems and ideas clear. Please ask me if it is > not so. > > Thanks in advance! > > > Regards, > > Jennie > -- Jan Rittinger Database Systems Technische Universität München (Germany) http://www-db.in.tum.de/~rittinge/

15 years, 9 months

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/compiler/debug abssynprint.c, 1.25, 1.26 coreprint.c, 1.26, 1.27

by Ying Zhang

On Tue, Oct 24, 2006 at 03:20:03PM +0000, Jens Teubner wrote: > Update of /cvsroot/monetdb/pathfinder/compiler/debug > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv19355/compiler/debug > > Modified Files: > abssynprint.c coreprint.c > Log Message: > Parser support for the `execute at' syntax extension (XRPC). > > Pathfinder's parser now recognizes expressions of the kind > > "execute" "at" "{" Expr "}" "{" FunctionCall "}" Hi Jens, Would you please change the implementation of the syntax according to the discussion on the syntax? The final version (I hope:)) of the syntax should be: "execute at" Expr "xquery" FunctionCall Thanks! Jennie > > where the expression in the first pair of braces specifies an > URI where the function call given in the second pair should > be evaluated at. Note that, in order to avoid parser conflicts, > we did not directly use the syntax proposed in a recent paper > submission, but rather this one that adds the curly braces. > > The system will try hard to convert the expression given in > the first pair of braces into a string. > > An expression as shown above will lead to a Core tree situation > that uses the new node kind `xrpc': > > xrpc > / \ > URI FunctionCall > > It's now Jennie's task to support that in the back-end. I suppose the change in the syntax won't affect the structure of this node kind? > TODO: If *not* touched the code that is currently existing in > Pathfinder and uses the "old" `import rpc-module' syntax. > Jennie, will you rip out this old stuff, once you have implemented > back-end support for the new syntax? Yep, I will. Jennie > > > Index: coreprint.c > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/compiler/debug/coreprint.c,v > retrieving revision 1.26 > retrieving revision 1.27 > diff -u -d -r1.26 -r1.27 > --- coreprint.c 25 Sep 2006 11:11:36 -0000 1.26 > +++ coreprint.c 24 Oct 2006 15:20:01 -0000 1.27 > @@ -132,6 +132,9 @@ > , [c_recursion] = "recursion" > , [c_seed] = "seed" > > + /* Pathfinder extension: XRPC */ > + , [c_xrpc] = "xrpc" > + > }; > > /** Current node id */ > > Index: abssynprint.c > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/compiler/debug/abssynprint.c,v > retrieving revision 1.25 > retrieving revision 1.26 > diff -u -d -r1.25 -r1.26 > --- abssynprint.c 25 Sep 2006 11:11:33 -0000 1.25 > +++ abssynprint.c 24 Oct 2006 15:20:01 -0000 1.26 > @@ -181,6 +181,9 @@ > /* Pathfinder extension: recursion */ > , [p_recursion] = "recursion" > , [p_seed] = "seed" > + > + /* Pathfinder extension: XRPC */ > + , [p_xrpc] = "xrpc" > }; > > /** Names of XPath axes */ > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins

15 years, 9 months

[Monetdb-developers] XRPC syntax

by Jens Teubner

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.

15 years, 9 months

Re: [Monetdb-developers] XRPC syntax

by Jens Teubner

Hi Peter, hi Jennie, On Tue, Oct 24, 2006 at 09:13:00PM +0200, Ying Zhang wrote: > 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 } | ... ] this syntax actually looks okay to me as well. The reason: XQuery is crafted in a way that it uses as few keywords as possible. To achieve that, the lexical analyzer (a) often recognizes patterns that are larger than a single word (matching "execute at" instead of "execute" removes the ambiguity with a child step searching for an `execute' element) and (b) switches parsing states depending on the symbols that the lexer sees. What we have here is that the lexical analyzer reads an expression. After reading an expression, it will *always* wait for an operator (e.g., an arithmetic operator, a sequence constructor, but also `as type', etc.). In this state it is safe to recognize a lot more keywords without making them ambiguous with, e.g., path steps. So if we throw in the `xquery' here, the state machine of the lexical analyzer should run fine again. `xquery' will be recognized as a keyword whenever an operator is expected, but not otherwise. Peter, Pathfinder's parser is strictly separated as it is supposed to be in a well-designed parser. There is a lexical analyzer, which is *independent* of the parser (done with bison in Pathfinder). Being unaware of any context information, our lexical analyzer thus cannot know that it currently is somewhere between the two components of an "execute at" clause. If you prefer the above syntax, I could implement that. It should be an easy fix. Just let me know. Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 No scientist is ever right, they just can't be proved wrong at the time! -- Richard Feynman

15 years, 9 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

developers-list October 2006