4728 2007-06-23 10:14:37 +0000 [FT] editorial: 4.3.1.1 Semantics of FTContainsExpr 2008-02-16 11:02:58 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Full Text 1.0 Last Call drafts All All CLOSED FIXED P2 minor --- 1 jmdyck holstege public-qt-comments oldest_to_newest 15556 0 jmdyck 2007-06-23 10:14:37 +0000 4.3.1.1 Semantics of FTContainsExpr [1] "EvaluationContext" Change to "SearchContext"? [2] "1. The sequence of items returned by EvalationContext" s/Evalation/Evaluation/ [3] "3. The sequence of nodes returned by IgnoreExpr," According to 3.7, IgnoreExpr has to be evaluated separately for each item in the search context, so there can't be a single sequence of nodes that works for all. 16949 1 holstege 2007-10-01 19:05:53 +0000 Item [1] fixed as proposed, which obviates the need to change item [2] 17156 2 holstege 2007-10-11 23:37:11 +0000 I don't believe it is possible to construct an example where it makes a difference whether you apply the unioned list of ignored nodes in one go or piecemeal. If you have a counter-example, please provide it. Given this belief, I propose modifying bullet 3 to say: The union of the sequences of nodes returned by IgnoreExpr for each search item, if that expression is present, or the empty sequence otherwise; and 17459 3 jmdyck 2007-10-27 01:30:57 +0000 (In reply to comment #2) > I don't believe it is possible to construct an example where it makes a > difference whether you apply the unioned list of ignored nodes in one go or > piecemeal. If you have a counter-example, please provide it. let $x = <example> <div> a <div> b </div> c </div> </example> return $x//div ftcontains "b" without content .//div The search context consists of two <div>s, outer and inner. For the outer, the ignore option excludes the inner (and thus, ftcontains does not see the "b"). For the inner, the ignore option excludes nothing (and thus, ftcontains sees the "b", and returns true). Whereas... The union of the exclusions is the inner <div>. If we were to exclude that union from every item in the search context, then when working with the inner div, we would exclude itself, and not see the "b", and return false. 17593 4 holstege 2007-11-05 17:14:34 +0000 As we discussed, I think at this point it would be best to remove the 2nd-orderness of the "without content" modifier, which is in keeping with what the semantics says, modify the sentence as suggested, and make the corresponding adjustments to section 3. Sample queries: Then this query would be an error (no context item): let $x = <example> <div> a <div> b </div> c </div> </example> return $x//div ftcontains "b" without content .//div This query would return false, because we're excluding all the divs: let $x = <example> <div> a <div> b </div> c </div> </example> return $x//div ftcontains "b" without content $x//div To get the alternative interpretation (removing just the divs under the search item), we could write: let $x = <example> <div> a <div> b </div> c </div> </example> return fn:exists($x//div[. ftcontains "b" without content .//div]) I propose that we lose the second-orderness of the ignored nodes expression. Then this query would be an error (no context item): let $x = <example> <div> a <div> b </div> c </div> </example> return $x//div ftcontains "b" without content .//div This query would return false, because we're excluding all the divs: let $x = <example> <div> a <div> b </div> c </div> </example> return $x//div ftcontains "b" without content $x//div To get the alternative interpretation (removing just the divs under the search item), we could write: let $x = <example> <div> a <div> b </div> c </div> </example> return fn:exists($x//div[. ftcontains "b" without content .//div]) I believe these makes the ftcontains expressions easier to understand, because the "without content" expression then follows the same rules as other expressions in XQuery. 18500 5 holstege 2008-01-24 15:05:31 +0000 Resolved to accept the change in semantics for [2] and make the relevant changes to the spec. Implemented. 18508 6 holstege 2008-01-24 16:08:41 +0000 Also implemented changes for point [3] by aligning the semantics as described in comment 4. 19101 7 jmdyck 2008-02-16 11:02:58 +0000 (In reply to comment #5) > Resolved to accept the change in semantics for [2] and make the relevant > changes to the spec. Implemented. [2] was just a typo-fix, not a change in semantics. So I think you meant [3]. But then comments #5 and #6 are both talking about [3]. Ah well, it's probably not important. Anyhow, closing this issue.