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