Date:         Mon, 10 Jan 2005 14:23:33 +0000
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Dr Robert Sanderson <[log in to unmask]>
Subject:      Re: Betr.: serverChoice interpretations
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Comments: cc: [log in to unmask]
In-Reply-To:  <[log in to unmask]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

> also think there may be a role for more specific "any"-like indexes
> corresponding to specific interpretations on Matthew's list (and maybe
> other interpretations not on that list, including the interpretation
> "search all fields even if they're not indexed, using grep on the raw
> data files if necessary").

I'm not sure that it makes much sense to say 'I don't know what I want,
nor what you have, but I want it to be from only one index'.  What's the
use case for such a distinction?

How about the following:

----------
cql.serverChoice:

This index is used with the index (and relation) are omitted from a search
clause.  The server will choose one or more indexes for the given term,
which may or may not otherwise be accessible to the end user.

cql.allIndexes:

Previously named cql.anywhere.
The server will search all indexes which are accessible to the end user
via CQL, in all context sets.

cql.allKnown:

The server will search all indexes which it has access to, even if the end
user does not.

cql.allFields

The server will attempt to search the complete record, potentially
including fields not indexed and not available via CQL to the end user.
------------





       ,'/:.          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