6813 2009-04-15 09:11:40 +0000 empty string full-text query 2011-01-06 15:46:32 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Full Text 1.0 Proposed Recommendation PC Linux CLOSED FIXED http://www.w3.org/TR/xpath-full-text-10/ P2 normal --- 1 peter.pleshachkov jim.melton jmdyck public-qt-comments oldest_to_newest 24734 0 peter.pleshachkov 2009-04-15 09:11:40 +0000 Dear authors, In the spec. you say that token is a none-empty string of characters. But if I have the following query : <p>petr</p>[. ftcontains ""] What is the result of this query ? And what is the result for this query <p>petr </p>[. ftcontains "petr" ftand ""] Kind regards, Petr 25489 1 jmdyck 2009-06-07 03:44:48 +0000 We have added wording to section 3.2 "Search Tokens and Phrases" to clarify various edge cases, including these. In both queries, the StringLiteral "" is an FTWordsValue, which evaluates to a single xs:string value, namely the empty string, which is then tokenized, presumably into an empty sequence of tokens. The associated FTAnyallOption is omitted, which is equivalent to 'any'. The relevant wording is now: If FTAnyallOption is "any", the sequence of tokens for each string is considered as a phrase. If the sequence of tokens is empty, then the phrase contributes nothing to the set of matches for the FTWords. So the empty string (with its empty sequence of tokens) contributes no matches, and there are no other strings in the value of the FTWordsValue, so the whole FTWords yields no matches. Propagating up from there, the FTContainsExpr yields false, so the query yields the empty sequence. We believe that the indicated wording change resolves this issue, so I am marking it resolved-FIXED. If you agree, please mark it CLOSED.