- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 01 Dec 2009 13:10:13 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8408 Summary: Clarification on StringExcludes and Windows Product: XPath / XQuery / XSLT Version: Candidate Recommendation Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Full Text 1.0 AssignedTo: jim.melton@acm.org ReportedBy: peter.fischer@inf.ethz.ch QAContact: public-qt-comments@w3.org In the CR, the following query (examples-362-5 in XQFTTS) is said to return an empty result when applied to the sample document (FT-3-examples-source-document.xml): /books/book[@number="1" and . contains text "efficient" ftand ftnot "and" window 3 words] The reasoning is that there is no occurrence of "efficient" within a window of 3 tokens which would not also contain an occurrence of "and". The formal definition of FTWindow seems to indicate a different result: - There are 3 (not 2) occurences of "and" in book, two within the <p> element and a third in the <title> element. Applying FTNot and then FTAnd would yield three matches, each with the StringInclude of the single occurence of "efficient" (within <p>), and a StringExlude that corresponds to the occurences of "and" - The StringInclude (trivially) fulfills the window condition for all three cases - According to 4.2.6.8, fts:ApplyFTWordWindow, only the StringExcludes are retained which are within the window limits. Clearly, the two StringExcludes within <p> fulfill this criterion, and are retained in the result. For the StringExclude stemming from <title>, the window condition is not fulfilled, therefore it is dropped. - As a consequence, there is now a Match without a StringExclude, causing the book to become part of the result Is my understanding of the semantics correct? If yes, a possible solution would be to modify the search context, as to search not inside <book>, but inside <p> -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 1 December 2009 13:10:14 UTC