Re: [FT] FTIgnoreOption

Dear Sihem
Thank you for your reply.

According to FT Specification 3.2.8, the example query:
/book[@number="1"] ftcontains "Testing" without content .//title
"returns false because "Testing" does not occur without the title 
element whose content is ignored."
But you suggested that search on a single word is no-op for FTIgnoreOption.
Would it be inconsistent?

Also I think it might be clearer if:
(nodeA ftcontains "some phrase" without content ./nodeB)
or
(nodeA ftcontains "word" without content ./nodeB)
simply requires the children nodeB's (and all its descendants) be pruned 
from nodeA before the keywords are searched.

Thanks,
Andrew

Sihem Amer-Yahia wrote:

>Dear Andrew,
>
>
>  
>
>>Dear Sihem,
>>Thanks for your reply.
>>
>>The following expression:
>>(nodeA ftcontains "some phrase" without content ./nodeB)
>>says only ignore the children nodeB's of nodeA. In this case, will the 
>>case (iii) still be considered a match?
>>
>>    
>>
>
>This is still under discussion. Both semantics are being considered
>for now. I explained the most general one in my previous email.
>
>  
>
>>The following expression:
>>(nodeA ftcontains "word" without content .//nodeB)
>>only searches a single word. In this case, would this be equivalent to:
>>(nodeA ftcontains "word")
>>? Or what is the semantics of a single word search with FTIgnoreOption 
>>specified?
>>
>>    
>>
>
>The 2 queries are equivalenet since it is a single word search.
>Ignoring content is a no-op in this context.
>
>  
>
>>Regarding FT specification 3.2.8, should the query be written as:
>>/book[@number="1"] ftcontains "Testing" without content .//title
>>Or can it be written as:
>>/book[@number="1"] ftcontains "Testing" without content 
>>/book[@number="1"]//title
>>? i.e. Does FTIgnoreOption require to use "." to specify the nodes to be 
>>ignored?
>>
>>    
>>
>
>The 2 queries are equivalenet since by definition, FTIgnoreOption
>ignores anything within the search context (i.e. in this case,
>/book[@number="1"]//title).
>
>
>Thanks,
>Sihem
>
>  
>

Received on Friday, 4 March 2005 04:34:27 UTC