Christian,

Since I have entered the bulk of the Use Case queries into the Test Suite, I can address your points 9-11:

[9] character-queries-results-q2.xml

OLD: <book number="2">...</book>
...This book should be exluded from the result as the wildcard string "resume."
will not accept "Resume testing".

>9.2.2 Q2 Diacritics Insensitive Query uses the diacritics insensitive match opinion. It should return Books 2 and 3 which contain resume either with or without diacritics. If you think I am missing something, please let me know, but Q2 was intended as a counter-point to Q1 Diacritics Sensitive Query which does not return Book 2 for the reason you cited.

[10] logical-queries-results-q2.xml

OLD: <book number="2">...</book> 
...should be excluded as well; "software" is not found here (so "web" ftand
"software" will yield false)

> Yes. My mistake. The results should be Books 1 and 3, not 2 as presented in the Use Cases. I have corrected the expected results in the test suite.

[11] logical-queries-results-q5.xml

OLD: <book number="2">...</book> 
...should be excluded as well, as "plan" is actually found here (so "usability"
ftand ftnot "plan" will yield false)

> Yes. My mistake. The results should be Books 1 and 3, not 2 as presented in the Use Cases. I have corrected the expected results in the test suite.

Thank you so much for implementing XQuery Full Text and for your assistance in polishing the Full Text Test Suite.

Pat Case, Librarian, Library of Congress, FTTF member

Pat,

thank you for the quick response. A little addition to point [9]..

>> OLD: <book number="2">...</book>
>> ...This book should be exluded from the result as the
>> wildcard string "resume." will not accept "Resume testing".
>
> 9.2.2 Q2 Diacritics Insensitive Query uses the diacritics insensitive match 
> opinion. It should return Books 2 and 3 which contain resume either with or
> without diacritics. If you think I am missing something, please let me know, 
> but Q2 was intended as a counter-point to Q1 Diacritics Sensitive Query which 
> does not return Book 2 for the reason you cited.

Yes, I agree with your comment regarding the diacritics check. However, regarding to section 3.4.2(.1) of the XQFT specs, I assume that the wildcard search "resume." will not match the word "Resume" in the discussed example due to the trailing dot. This case corresponds to the following example (1), whereas (2) would indeed return true:

 (1) 'Resume testing' ftcontains 'resume.' with wildcards
 (2) 'Resume testing' ftcontains 'resum.'  with wildcards

Please correct me if I misinterpreted the specification.
Thanks,

Christian, BaseX Team 
http://www.basex.org

Christian,

Re: Yes, I agree with your comment regarding the diacritics check. However,
regarding to section 3.4.2(.1) of the XQFT specs, I assume that the wildcard
search "resume." will not match the word "Resume" in the discussed example due
to the trailing dot. This case corresponds to the following example (1),
whereas (2) would indeed return true:

 (1) 'Resume testing' ftcontains 'resume.' with wildcards
 (2) 'Resume testing' ftcontains 'resum.'  with wildcards

>Yes. You are absolutely correct. 

In both Q1 Diacritics Sensitive Query and Q2 Diacritics Insensitive Query the with wildcards is supposed to allow for the possibly of 1 or more suffix characters to allow the sample text to illustrate the use of the diacritics match options. My mistake was using . with wildcards instead of .? with wildcards.

I have corrected it in test suite queries (leaving the expected results as they were) and the next version of the use cases document will show the changes as well.

Thanks so much.

Pat

Items #8 and #14: corrected as suggested.

Christian,

Re: [13] wildcard-queries-results-q3.xq / q4.xq ...a closing parenthesis is missing at the end of the queries.

It appears that this one is mine also

You are of course correct. I have added additional closing parentheses to the XQuery queries for Wildcard Q3 and Q4 in the test suite and in the use case document.

Thanks again for pointing this stuff out.

Pat Case

Christian, this response addresses the remaining items that have not been addressed already by others. 

[3] xpath-full-text-10.xml & ExpectedResults//*

OLD: FTAnyallOptions
NEW: FTAnyallOption

...this typo also affects the XQFT specification.

>>> You are obviously correct, and the error has been corrected both in the specification and in the test suite result files. 


[4] ExpectedResults/.../FTWords/*

OLD: containment is checked.</p>
NEW: containment is checked. </p>

OLD: FTAnyallOption</nt>produces
NEW: FTAnyallOption</nt> produces

OLD: FTWordsValue</nt>is
NEW: FTWordsValue</nt> is


>>> You are obviously correct, and the error has been corrected both in the specification and in the test suite result files. 


[5] FTPrimary-FTWords-*

OLD: //div2[id="ftwords"]
NEW: //div2[@id="ftwords"]

>>> You are obviously correct, and the error has been corrected both in the specification and in the test suite result files. 


[6] FTPrimary-FTWords-q1b.xq

OLD: $p ftcontains { $input-context }
NEW: $p ftcontains { $search-token }

>>> You are obviously correct, and the error has been corrected both in the specification and in the test suite result files. 

..but indeed a query like the following - which should always yield true -
could be an interesting one:

 doc("doc.xml") ftcontains { doc("doc.xml") }

>>>Undoubtedly true, but I'm not creating such a test at this time. 


[7] FTPrimary-FTWords-q4b.xq

OLD: <paragraphs></paragraphs>
NEW: </paragraphs>

>>>This has been overtaken by events. 

>>>BE AWARE: I have heavily restructured the FTPrimary-FTWordss-* series of tests and their results to better capture all of the various behaviors.  As of the time I'm writing this comment, I'm about 60% done; I still have "all" and "all words" left to do. 


[12] FTSelection-Weight-q1e.xq

...the error code "FTDY0016" is not accepted as a result.

>>>Good catch!


[15] FTSelection-Weight-q3.xq

OLD: Error "FTDY0016"
NEW: Error "XPTY0004"

...according to the specs, FTDY0016 is only thrown for negative numbers here.


>>> You are obviously correct, and the error has been corrected both in the specification and in the test suite result files. 

Thanks again for your very thorough review and your excellent reports. 

I believe that we have now addressed all of the problems that you reported in this bug except for items [1] and [2]. 

WRT item 1: 
Examples 1-5 should remain in 2.3-ScoreVariables; example 6 should move to 
2.3.1-UsingWeightsWithinAScoredFTContainsExpr. Updated catalog and queries and expected results to accord with this.

WRT item 2: 
Fixed as indicated.

I believe this resolves all issues with this bug.  Please close the bug if you are satisfied with this resolution.