Date:         Sun, 9 Jan 2005 23:41:00 +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: 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

>> Why shouldn't this be allowed?

> For reasons outline that this leads to queries involving serverChoice
> which cannot be performed by explicitly requesting indexes.
> It isn't the default value that is at issue, it is that the default
> value in cases ii,iii,v and vi are values which would not normally be
> allowed in CQL queries sent to that server.

Okay... and why shouldn't /that/ be allowed?


> My view would be that if a server returns simple Dublin Core when the
> recordSchema is omitted by the client, then I don't see why the client
> can't explicitly request that record schema and expect to get it.

Then you're also arguing against
cql.allKnown/adlib.whateverHedzerCallsHisIndex, which searches indexes
which are otherwise unsearchable?

> Similarly if the server uses a particular index when
> omitted/serverChoice I don't see why the client can't explicitly ask for
> for that index in a query.

That could be done, but what gain is there by making it mandatory to do
it?  I just don't see one when you can get it by using cql.serverChoice.

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