> 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
> ii) the server always uses the same index, [which is equivalent to a
> combination of other indexes]
> iii) the server always uses the same index, however this is not
> equivalent to any CQL index
> iv) the server choices an index based on contextual analysis of the
> query (typically the term) but otherwise as per case (i),
> v) the server choices an index based on contextual analysis of the query
> but otherwise as per case (ii)
> vi) the server choices an index based on contextual analysis of the
> query but otherwise as per case (iii)


> 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.

I think the consensus to date has been that if the server is using case
(i) then it should Explain it.  As this is the easiest option to
implement, it's likely to happen a lot, and hence we should take it into
account.

> There certainly isn't consensus that all six interpretations are valid.

I'm perfectly happy for all 6 to be valid, FWIW.

> (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.

Why shouldn't this be allowed?  If all I want to do is have a trivial
Google like interface (eg the server -only- accepts serverChoice) then why
shouldn't I?

If I only want to search on a magical 'topic' index if the searcher
doesn't know what they really want, because it's a slow index to search
(being made up of lots of different fields) or because it's a generally
low quality index (ditto), then why should I expose that separately?
More importantly, as every database will have a different make up for
their 'topic' index, I would probably have to have my own context set and
index to expose it... at which point, it doesn't actually gain anything.

If (iv) is okay and ii and iii are okay, that means (to me) that (v) and
(vi) are okay too.

This is all perfectly consistent with the rest of CQL and SRW-- if you
know what you want, then you ask for it and the server MUST honor your
request or tell you that it can't.  If you don't know what you want, you
leave it out, and the server supplies a default value.

Here's another example:

If I don't supply recordSchema, and ask for 1 record, the server should be
able to respond with a full record (eg EAD or METS or MODS).  On the other
hand if I ask for 50 records, then the server should be able to respond
with a brief record (eg simple dublin core)
This is the same as serverChoice mapping to different indexes (iv-vi)
based on the rest of the query.

Rob

       ,'/:.          Dr Robert Sanderson ([log in to unmask])
     ,'-/::::.        http://www.o-r-g.org/~azaroth/
   ,'--/::(@)::.      Dept. of Computer Science, Room 805
,'---/::::::::::.    University of Liverpool
____/:::::::::::::.  L5R Shop: http://www.cardsnotwords.com/
I L L U M I N A T I