4730 2007-06-23 10:15:34 +0000 [FT] editorial: 5.2.14 Scoring 2007-10-11 22:29:02 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Full Text 1.0 Last Call drafts All All CLOSED FIXED P2 minor --- 1 jmdyck mrys public-qt-comments oldest_to_newest 15558 0 jmdyck 2007-06-23 10:15:34 +0000 5.2.14 Scoring [1] "a combination of FTContainsExpr" s/FTContainsExpr/FTContainsExprs/ [2] "formed with the XQuery Boolean operators 'and' and 'or'" What about "not" ? [3] why In the case of ForClause and SimpleForClause, the scoring restriction doesn't make much sense: if the ExprSingle satisfies the restriction, it can only return a boolean, and what's the point of iterating over a singleton boolean? Note that none of the ForClauses or SimpleForClauses in this spec's examples satisfy this restriction. Ditto in the Use Cases. 17153 1 mrys 2007-10-11 22:28:32 +0000 (In reply to comment #0) > 5.2.14 Scoring > [1] > "a combination of FTContainsExpr" > s/FTContainsExpr/FTContainsExprs/ this becomes mood with change for [3]. > [2] > "formed with the XQuery Boolean operators 'and' and 'or'" > What about "not" ? This becomes mood based on change for [3]. Also note that the set of supported expressions is implementation-defined according to 3.2. > [3] > why > In the case of ForClause and SimpleForClause, the scoring restriction > doesn't make much sense: if the ExprSingle satisfies the restriction, > it can only return a boolean, and what's the point of iterating over a > singleton boolean? > Note that none of the ForClauses or SimpleForClauses in this spec's > examples satisfy this restriction. Ditto in the Use Cases. Section 3.2 says that set of supported expression is implementation-defined. The section will be reworded. The first paragraph will say that implementations can restrict allowable expressions and they are implementation-defined. The second paragraph gets removed and the third one gets a slight editorial adjustment. Since you were present when we discussed the changes I am resolving and closing the bug.