3419 2006-06-30 22:18:26 +0000 AllMatches model fails to represent correct semantics of FTUnaryNot 2006-08-16 17:47:11 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Full Text 1.0 Working drafts PC Windows XP CLOSED FIXED http://www.w3.org/TR/xquery-full-text/#tq-ft-fs-FTUnaryNot P1 major --- 1 joaquin.delgado jim.melton public-qt-comments oldest_to_newest 10339 0 joaquin.delgado 2006-06-30 22:18:26 +0000 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 10418 1 joaquin.delgado 2006-07-07 00:12:11 +0000 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.