Date:         Mon, 10 Jan 2005 09:51:06 -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:      Re: serverChoice interpretations
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Content-Type: text/plain; charset="us-ascii"

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

Because the spec current says so - "By contrast, cql.serverChoice means
essentially "search any index -- your choice -- from any context set you
know"." The page
http://www.loc.gov/z3950/agency/zing/cql/context-sets/cql.html indicates
that both cql.anywhere and cql.serverChoice roam over indexes from
context sets the server knows. Hence why adlib need a new anywhere which
can include inaccessible indexes to CQL, and it appears Ralph needs a
new serverChoice.

Essentialy, I'm arguing that the semantics of omission (and ipse facto
serverChoice) is that the server can subsititute an existing index from
a known context set. This is what the spec current indicates: "If no
index is supplied, then it is determined by the server",
"'cql.serverChoice' means that the server will choose an index for the
given term", "By contrast, cql.serverChoice means essentially "search
any index -- your choice -- from any context set you know".)"

The semantics of serverChoice that you and Ralph are arguing for are
very different. In this case serverChoice essentially means that the
server will choose records that it feels fit the search term (without
any necessary reference to existing context set indexes). If this is
really the case, then the CQL spec.s for omission and serverChoice need
rewriting as they are at best misleading if not wrong.
 
 
> > 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?

No - I don't recall ever saying that - the semantics of serverChoice has
no impact of the semantics of any other index definition! 

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

You can in cases ii and iii admittedly as cql.serverChoice would always
use that inaccessible index (although since it is not a CQL index you
can't indicate that in the explain). However, in cases v and vi,
cql.serverChoice might use (say) Ralph.BasicIndex at certain times but
not at others, so the client could never explicitly ask for
Ralph.BasicIndex and consistently get it.

Matthew