This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6198 - [FT] TestSuite - Weight 0
Summary: [FT] TestSuite - Weight 0
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Full Text 1.0 (show other bugs)
Version: Candidate Recommendation
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Jim Melton
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL: http://basex.org/
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-31 07:56 UTC by Christian Gruen
Modified: 2008-11-07 15:00 UTC (History)
0 users

See Also:


Attachments

Description Christian Gruen 2008-10-31 07:56:13 UTC
Hi,

the last post for today.. The query "FTSelection-Weight-q1b.xq" sets the weight of all results to 0.0. This is why I would expect 0 hits here. Instead, the current test suite file includes results.

If results are correct for this query, an implementation would have to make an explicit distinction between false hits and hits with "0.0" as scoring value - this is probably not what implementors and users would expect. Last but not least, if 0.0 scores are valid results, this should at least be implementation dependent.

Thanks,

Christian, BaseX Team 
http://www.basex.org
Comment 1 Jim Melton 2008-11-06 23:29:47 UTC
Christian, your report has merit, but recall that the meaning of weight values is implementation-defined (or is that -dependent?).  There is nothing in the spec that says that a weight of 0.0 means "ignore this part of the query", so the assumption that the query should return nothing is mistaken.  We all believe, of course, that a query term with a weight of 0.0 should be considered "less relevant" or "less important" than a query term with a weight of 999.999, but that's not guaranteed by the spec. 

Nonetheless, it's probably appropriate to give two alternate possible results -- one as it's already specified, but the other as "empty result".  It is perfectly reasonable, even though not required, that an implementation would choose to interpret 0.0 to mean "completely irrelevant". 

Thanks for the report.  I'll go ahead and add that second alternative result, so I'm marking this bug as FIXED.  If you agree with this resolution, please mark the bug CLOSED. 
Comment 2 Christian Gruen 2008-11-07 15:00:05 UTC
Dear Jim,
thank you for the detailed comments. Yes, an alternative result surely is the best solution here to consider different implementations. I've closed this bug.

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