[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: result size precision
Based on discussion the past several years over the
topic of result size precision, the OASIS Search Web Service Technical Committee
proposes to define in SRU 2.0 an optional response element
<resultSizePrecision> whose definition would be something
like:
"The server's confidence in the
precision of the result count reported. A non-negative integer from zero to
100. A value of zero means the server has no idea what the size of the
result set is. '100' means the server guarantees that the value of result
count is accurate. A value in between means the result count is an
estimate, where a higher value means that the server has more confidence in the
precision than a lower value."
[Note: the committee debated an alternative, where
there would be three values: 'exact', 'estimate', 'no idea'. However,
the committee felt that might be inflexible, and there might eventually be
implementors who would want four levels, five, etc. With the zero to
100 approach, a convention could be recommended to use zero, 50, and 100 for the
three-level representation.]
That's the server side, comments are welcome.
At the other end is the client side. Should the client indicate that it does or does not care about result size precision? It might want 10 records, any 10, and beyond that it doesn't care if there are 10 or 10 billion, and it does not want the client to bother to even try to determine or estimate the result size, as that may be an expensive process. The TC is inclined not to address this, the client end, unless someone can cite a real requirement (not just "it seems useful"). So we are soliciting feedback on this question from SRU implementors. Can someone assert that if a request parameter were to be defined pertaining to result size precision, you would implement it? Ray Denenberg
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]