This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
Item [1] fixed as proposed, which obviates the need to change item [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. 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
(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.
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.
Resolved to accept the change in semantics for [2] and make the relevant changes to the spec. Implemented.
Also implemented changes for point [3] by aligning the semantics as described in comment 4.
(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.