2331 2005-10-07 16:48:36 +0000 FLWORExpr and QuantifiedExpr symmetry. 2007-02-25 23:47:46 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 1.0 Last Call drafts PC Windows XP CLOSED WONTFIX P2 normal --- 1 dholmes chamberl public-qt-comments oldest_to_newest 6659 0 dholmes 2005-10-07 16:48:37 +0000 In studying FLWOR and Quantified expressions together, I noted some differences that struck me as rather odd and indicated that the Quantified expression might be incomplete. 1. FLOWRExpr supports assignment of a full sequence to a variable whereas QuantifiedExpr does not. More precisely, FLWORExpr supports both "in" and ":=" clauses whereas QuantifiedExpr only supports "in". 2. FLOWRExpr supports positional variables for its "in" clause whereas QuantifiedExpr does not. In addition, I had also wondered whether the use of both "for" and "in" together, and "let and "::=" together was somewhat redundant. The grammar requires me to prefix a "for" or a "let" token when the "=" or "::=" token already defines my intention (There may be some practical parser consideration I'm missing here). It seems to me that there might be a more uniform syntax that solves all of these problems and also emphasizes the functional nature of the language. ReturnExpr ::= "given" BindingSpecification WhereClause? OrderByClause? "return" ExprSingle QuantifiedExpr ::= "given" BindingSpecification ("some"|"every") ExprSingle BindingSpecification ::= (InClause | AssignClause)+ InClause ::= "$" VarName TypeDeclaration? "in" ExprSingle PositionalVar? AssignClause ::= "$" VarName TypeDeclaration? ":=" ExprSingle I've suggested moving the PositionalVar to the end to simplify parsing. Examples: given $x in (1,2,3), $y := (2,3,4) return $x + $y if (given $x in (1,2,3), $y := (2,3,4) some $x + $y = 4) then ... 6660 1 mike 2005-10-07 17:05:51 +0000 The XQuery spec has been through about ten drafts including two last calls. It's always possible to come up with improvements to any language, but it must surely be fairly obvious that if we ever want to finish, we've got to focus efforts on fixing the few remaining corner cases rather than throwing everything up in the air. I find it hard to imagine why you think this is a useful comment to raise at this time: you're not actually suggesting the language is broken in any way. Michael Kay (personal response) 8248 2 chamberl 2006-02-14 00:17:53 +0000 David, Thanks for your comment. Your suggestion was discussed by the Query working group on Feb. 1, 2006. The working group believes that it is not appropriate to make major changes to the XQuery grammar at this point in the design process unless significant problems are discovered, which does not seem to be the case with this suggestion. Therefore, the working group does not plan to change the XQuery language specification in response to this comment. If you disagree with this resolution, please respond with evidence why your comment represents a major defect in functionality rather than simply a cosmetic issue. In the absence of such evidence, we will close this issue at the end of February 2006 (or you may close it yourself if you agree.) Regards, Don Chamberlin (for the Query Working Group) 14155 3 jim.melton 2007-02-25 23:47:46 +0000 Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.