This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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".
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.
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.
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.
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.
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"}
Yup, I think you're right.
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.
My experiments with parser generation confirm that this solution works. I agree that the problem is fixed.