W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2006

[Bug 3419] AllMatches model fails to represent correct semantics of FTUnaryNot

From: <bugzilla@wiggum.w3.org>
Date: Fri, 30 Jun 2006 22:18:26 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1FwRJi-0002Wn-TC@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3419

           Summary: AllMatches model fails to represent correct semantics of
                    FTUnaryNot
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
               URL: http://www.w3.org/TR/xquery-full-text/#tq-ft-fs-
                    FTUnaryNot
        OS/Version: Windows XP
            Status: NEW
          Severity: major
          Priority: P1
         Component: Full Text
        AssignedTo: jim.melton@acm.org
        ReportedBy: joaquin.delgado@oracle.com
         QAContact: public-qt-comments@w3.org


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
Received on Friday, 30 June 2006 22:18:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:12 UTC