This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In section 3.1.5 (FTUnaryNot) the following example is given /book[. ftcontains ! "usability"] which following the evaluation efectively returns the empty sequence because all book elements contains "usability". However if one were to write /book[. ftcontains ! "XSLT"] The expected results is all book elements because the expression (! "XSLT") evaluates TRUE for all books which do not contain the word "XSLT". However in the semantics defined with the AllMatches model in http://www.w3.org/TR/xquery-full-text/#tq-ft-fs-FTUnaryNot this fails. Esencially the evaluation of FTWords returns no match (no stringInclude) and therefore the negation of an empty match is empty as well, thus the evaluation returs FALSE when it should return TRUE for all books. That is because we do not handle the concept of complement (e.g. *) that represents the rest of the world that is not a match. This problem can be avoided if we only support AND NOT instead of UnaryNot or introduce the representation of complement in cases where there is negation of an empty match. -- Joaquin
This standalone UnaryNot does not have a bug. The negation of an empty <allMatches> is not an empty <allMatches> but an <allMatches> with one empty <match>. That is clear in the definition of fts:UnaryNotHelper. It populates <match/> when there is no <match> in <allMatches>. This empty <match> element satisfies fts:FTContainsExpr because it has no <stringExclude>. So, ftcontains returns TRUE as expected. Thanks, J.D.