Date:         Sat, 8 Jan 2005 17:03:09 -0000
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         "Matthew J. Dovey" <[log in to unmask]>
Subject:      serverChoice interpretations
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Content-Type: text/plain; charset="us-ascii"

> I do think the distinctions between these various special indexes are
> potentially important and well worth the effort of getting right;

Let me clarify (hopefully rather than obfuscate) where I think we are!

*******

Firstly, to avoid confusion, I'll define a few terms.

I regard two queries as "equivalent" if they produce the same result set
(although they may of course have totally different search execution
paths).

I regard two CQL indexes to be equivalent if given any CQL query, a
simple substitution of one index for the other index produces an
equivalent query.


*******

We seem to have the following potential interpretations of
serverChoice/omission:

i) the server always uses the same index which is equivalent to some CQL
index which the server would allow in queries - i.e. serverChoice is
equivalent to an accepted CQL index. This would be the case if the
server always chose a dc.title search for example.

ii) the server always uses the same index, however this is not
equivalent to any CQL index the server would allow in queries. However,
the query is always equivalent to some CQL query the server would
accept. This would be the case if the server searched a combined index
of dc.title and dc.subject.

iii) the server always uses the same index, however this is not
equivalent to any CQL index the server would allow in queries, nor is
there necessarily any equivalent CQL query which the server would
accept. This would be the case if the server did a free text search of
the record (but did not offer a free text search any other way).

iv) the server choices an index based on contextual analysis of the
query (typically the term) but otherwise as per case (i), i.e. the index
chosen is always equivalent to some CQL index the server woulld allow in
queries.

v) the server choices an index based on contextual analysis of the query
but otherwise as per case (ii) i.e. that the index is not necessarily
equivalent any CQL index, but the query is equivalent to some CQL query
the server would accept.

vi) the server choices an index based on contextual analysis of the
query but otherwise as per case (iii) i.e. that the index is not
necessarily equivalent any CQL index, nor is the query necessarily
equivalent to any CQL query the server would accept.


******

Firstly, although I knew that omission and serverChoice had the same
semantics, I hadn't appreciated that they had to be equivalent indexes.
As Mike and Rob have pointed out, the current spec.s do so thay this
must be the case. I'm not sure I'd had agreed with this if I'd
appreciated it at the time though as I'd always thought of omission as
being the server defaulting to an index (e.g. case (i)) whilst
serverChoice implying that the server would be chosing an index (e.g.
case (iv)). 

Secondly, with the exception of case (i) where you can use
/explain/configInfo/default[@type='index'] in the explain record, there
is no way of determining which of the above interpretations the server
may be using. I'm not sure that there is consensus that the client
should know.

There certainly isn't consensus that all six interpretations are valid.
I would argue that only (i) and (iv) are valid since there is an
implication that the server is chosing an existing CQL index to
subsitute for serverChoice or omission. This is supported by the current
text in the CQL defintions which says under the definition of anywhere
""(By contrast, cql.serverChoice means essentially "search any index --
your choice -- from any context set you know".)". This needs to be
qualified as Ralph is currently using either (ii) or (iii) in his
implementation.

In fact from the description Ralph's implementation may be close to
(iii) - I'm not sure I'm happy about allowing this as a valid
interpretation as in my view serverChoice should be used when the client
doesn't care how the search is done, not as a way of doing a search
which is not otherwise possible using the indexes otherwise supported by
the server.


Matthew