3931 2006-11-01 00:34:26 +0000 [FT] Section 3.2.5: order of options 2007-04-19 15:12:48 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Full Text 1.0 Working drafts PC Windows XP CLOSED FIXED P2 normal --- 1 mrys jim.melton public-qt-comments oldest_to_newest 12729 0 mrys 2006-11-01 00:34:26 +0000 /book[@number="1"]//p ftcontains "propagation of errors" with stemming with stop words ("a", "the", "of") Does stemming apply to stop words list too or do you first get stop words applied… is that query different from: /book[@number="1"]//p ftcontains "propagation of errors" with stop words ("a", "the", "of") with stemming? 13864 1 pcase 2007-01-31 18:48:13 +0000 In 3.2 FTMatchOptions, it says that FTMatchOptions are applied in the order in which they are written in the query. So yes the queries are different. Stemming and stop words are applied in the order written. You stem words in the query. You replace stop words with any word. So the user can stem the words in the query before or after the stop words are replaced. So if we have "to be or not to be" with stemming with stop words ("be") --You would stem all the words in query including "be", then replace "be". You might end up with "being" in your query, but it doesn't matter because you will find any word in the position of the "be" which includes "being" anyway. "to be or not to be" with stop words ("not") with stemming --You would replace "be", then stem all the words left in query. You will get the results you get above. Either way it would be spitting in the wind to say "with stop word x" and to search for X in your query, but you will get the same results, possibly nasty, results. And it appears that only when they are the same that there might have been a difference in the results. In 4.2.3 The evaluate function, we say: Ordering among match options is necessary because match options are not always commutative. For example, synonym(stem(word)) is not always the same as stem(synonym(word)). Naturally, match options may be reordered when they commute, but this is an optimization issue and is beyond the scope of this document. So I don't think there is any need to protect users and we have said that implementations can vary the order to optimize, so I think the spec is clear here, the results are satisfactory, and there is no need for change. Might I mark this won't fix? 14007 2 jim.melton 2007-02-18 23:09:01 +0000 Changes were adopted by the TF at its recent F2F that respond to your questions. Specifically, it was agreed that the various FTMatchOptions would be applied in a specific sequence, as you agreed during the meeting. This bug remains open pending review of the actual changes to the spec. 14766 3 jim.melton 2007-04-19 15:12:37 +0000 The changes agreed for this bug have been reviewed by the TF, which approves the wording. Therefore, this bug is marked FIXED. Since you were present when the review took place we assume that you are satisfied with this resolution to your comment and have also marked it CLOSED.