This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
3.2 Search Tokens and Phrases [1] para 3 'The FTWordsValue is converted as though it were an argument to a function with the expected type of "xs:string*".' This sentence belongs in para 5, with some accomodation: The following rules specify how an FTWordsValue matches tokens and phrases. First, the FTWordsValue is converted to a sequence of strings as though it were an argument to a function with the expected type of "xs:string*". Then, each of those strings is tokenized ... [2] any, all "the sequence of tokens for every string is considered as a phrase," s/every/each/ [3] any "If the sequence contains more than one string" This might be confusing, because the most recent reference to a sequence was a sequence of tokens. s/the sequence/the value of the FTWordsValue/ [4] examples '/book[@number="1" and ...' The examples might be more natural if you left out the @number="1" condition.
I have fixed section 3.2 as proposed in [1], [2], and [3]. Regarding proposal [4], I have eliminated the @number=1 in all but one example. I think we should have an example rather early that shows that FTContainsExpr can be used with the XQuery Booleans.
The change for [3] doesn't appear to have been committed. Re [4], I agree that it would be good to give an early example of FTContainsExpr with a boolean operator. But note that section 2.3's first example already does. Section 2.2.2 would also be a good place for such an example; e.g., one could insert "$b/price < 20 and" into the first example.
This is now done. I eliminated @number=1 from all the examples within 3.2 Search Tokens and Phrases. Please also review the additional exmaple (with price < 50) in 2.2.2.