6927 2009-05-20 15:22:26 +0000 XQuery 1.1 is not an LL(k) language because of the optional "outer" keyword 2009-09-17 20:30:10 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3.0 Working drafts All All RESOLVED FIXED needsDrafting P2 major --- 1 gabriel.petrovay jonathan.robie jim.melton mike nikolay.ognyanov public-qt-comments oldest_to_newest 25221 0 gabriel.petrovay 2009-05-20 15:22:26 +0000 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 25232 1 mike 2009-05-20 19:45:26 +0000 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? 25238 2 gabriel.petrovay 2009-05-20 19:53:16 +0000 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 25239 3 mike 2009-05-20 20:05:27 +0000 >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. 26366 4 nikolay.ognyanov 2009-08-10 22:18:01 +0000 *** Bug 7257 has been marked as a duplicate of this bug. *** 26649 5 jonathan.robie 2009-08-25 13:14:18 +0000 (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. 26652 6 mike 2009-08-25 13:27:38 +0000 for $x in EXPR even when empty ... ? 27264 7 jonathan.robie 2009-09-17 20:30:10 +0000 On July 7th, the Working Group agreed to replace "outer for" with "for ... allowing empty", where "allowing empty" comes between TypeDeclaration? and PositionalVar?.