7247 2009-08-09 09:46:16 +0000 xquery full text grammar ambiguity? 2009-12-08 20:31:37 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Full Text 1.0 Candidate Recommendation PC Linux CLOSED FIXED P2 normal --- 1 nikolay.ognyanov jim.melton jmdyck Probst_Martin public-qt-comments oldest_to_newest 26323 0 nikolay.ognyanov 2009-08-09 09:46:16 +0000 Consider the following expression: element ftcontains {'whatever'} Without full text it is clearly a computed element constructor. With full text though it seems to also be FtContainsExpr by the rule FTContainsExpr ::= RangeExpr ( "ftcontains" FTSelection FTIgnoreOption? )? since 'element' is a valid relative path and hence - RangeExpr and '{'whatever'}' is a valid FtWordsValue and hence - FTSelection. I am not able to find in candidate recommendation from 07/09/2009 anything that would resolve this ambiguity. Am I missing something? Similar constructs seem possible with 'ftand' and 'ftor' and with other computed constructors. Root cause of the problem seems to be the "naked" curly bracket construct in FTWordsValue. There used to be similar problems with "naked" blocks in Scripting which were resolved by lead-in token "block". 26353 1 nikolay.ognyanov 2009-08-10 13:45:09 +0000 P.S.: Sorry, I should have possibly suggested a fix (in case I am not mistaken about the ambiguity). What I would suggest is modification of the rule for FTWordsValue as follows: FTWordsValue ::= Literal | ("words" "{" Expr "}") The unhappy disadvantage of this is more verbose syntax of Full Text. The advantage which IMO prevails is upward compatibility with XQuery in the example above and similar. 27036 2 jim.melton 2009-09-11 02:12:43 +0000 This is a status report, not an indication of completion: The Full Text Task Force, as well as the XML Query and XSL WGs, are currently wrestling with this issue. One fix was suggested that solved the problem at the cost of some confusion to novice full-text users, but the WGs have pushed back a bit asking for further thought to be given to other possible solutions. 28141 3 jim.melton 2009-10-08 22:22:51 +0000 In its teleconference of 2009-09-28, the Full Text Task Force adopted a solution to this bug that was prescribed by the joint XSL WG and XML Query WG teleconference of 2009-09-22. That solution is to replace the keyword "ftcontains" with the keyword pair "contains text". As a result of this change, I have marked this bog RESOLVED/FIXED. If you accept this resolution, please mark it CLOSED. 28364 4 nikolay.ognyanov 2009-10-15 13:37:38 +0000 I agree that this solves the ambiguity caused by "ftcontains". I still experience some problems with by "ftand" and "ftor" but those may hopefully be fixed with the fix for bug #7271. 28387 5 nikolay.ognyanov 2009-10-16 01:17:48 +0000 P.S. : Unfortunately problems with "ftand" and "ftor" persist after implementation of the fix for bug #7271. Some experiments with tweaking the grammar make me believe that problems occur when these 2 are used in conjunction with "weight" and computed constructors. One example of the kind seems to be this: a contains text {"something"} weight element ftand {"other"} 28388 6 jmdyck 2009-10-16 02:20:52 +0000 Yup, I think you're right. 29978 7 jmdyck 2009-12-08 00:34:11 +0000 Our solution to the problem raised in comment #5 is to change the syntax of FTWeight to require braces around the weight expression: FTWeight ::= "weight" "{" Expr "}" We're fairly confident that this change doesn't raise any other parsing problems. Consequently, I'm marking this bug Fixed. If you agree, please mark it Closed. 30020 8 nikolay.ognyanov 2009-12-08 20:31:37 +0000 My experiments with parser generation confirm that this solution works. I agree that the problem is fixed.