This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Hi all, XQuery 1.1 is not an LL(k) language because of the optional "outer" keyword (yes I know XQuery has no keywords). Take the following 2 correct queries: 1. for $x in outer for $y in Expr return 2 2. for $x in outer for $y in Expr return 2 return 3 The parser has a problem when parsing the "outer for" token sequence because it does not know which production to take next because of the OPTIONAL "outer" keyword. Is it a nested "outer for" or the "outer" step expression followed by a simple "for" clause? Of course that, by reading the whole input you can determine if the expression is correct, but the language is not anymore an LL(k) one. This is because for any k > 0, one can find an expression (Expr) having [number of tokens] > k such that the parser cannot parse the language. Regards, Gabriel
Good catch, I think you are right. Perhaps we could use "outerfor" as a single word. Though I really wonder how many people understand this "outer" terminology anyway? Not all our users have done a computer science SQL course, and even those who have might not immediately see the relevance. It seems very obscurely related to the actual semantics. Might something like for $x emptiable? in EXPR be better?
Hi Mike, I had several SQL computer science courses but "emptiable" doesn't sound familiar to me. "Outer" is a good word. It is also similar to most JOIN terminology for SQL languages. It is just that the syntax must be corrected in my opinion. Cheers, Gabriel 28msec.com
>I had several SQL computer science courses but "emptiable" doesn't sound familiar to me. "Outer" is a good word. It is also similar to most JOIN terminology for SQL languages. Perhaps you misread my point: I was suggesting that the concept of "outer join", and its relationship to the semantics of FLOWR expressions, would only be understood by those with an advanced computer science education, whereas "emptiable" might be more accessible/memorable to the masses.
*** Bug 7257 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Good catch, I think you are right. > > Perhaps we could use "outerfor" as a single word. > > Though I really wonder how many people understand this "outer" terminology > anyway? Not all our users have done a computer science SQL course, and even > those who have might not immediately see the relevance. It seems very obscurely > related to the actual semantics. Might something like > > for $x emptiable? in EXPR > > be better? The word "outer" does not really play a role in these semantics as they are defined in the specification. The semantics of the expression are "If the binding sequence contains no items, the output tuple stream depends on the presence or absence of the outer keyword. If outer is specified, the output tuple stream consists of one tuple in which the variable is bound to an empty sequence. If outer is not specified, the output tuple stream consists of zero tuples." It would be nice to have a syntax that reflects these semantics more directly, specifying what to do if the binding sequence is empty. I'm not sure "emptiable" does that. I can't think of a beautiful syntax that does. Perhaps: for $x in EXPR or empty Or use a ? after the expression to indicate that empty is allowed: for $x in EXPR? We might allow () or any other value to be specified as a parameter, to be used of the binding expression is empty: for $x in EXPR or () Or (more verbose but more explicit): for $x in EXPR on empty () Regardless, I agree with Mike Kay that "outer" is not helpful in this syntax.
for $x in EXPR even when empty ... ?
On July 7th, the Working Group agreed to replace "outer for" with "for ... allowing empty", where "allowing empty" comes between TypeDeclaration? and PositionalVar?.