Date:         Thu, 31 Jan 2002 14:57:50 +1100
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Alan Kent <[log in to unmask]>
Subject:      Re: ZiNG
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
In-Reply-To:  <[log in to unmask]>; from Matthew Dovey on Wed, Jan 30,
              2002 at 10:52:45AM -0000
Content-Type: text/plain; charset=us-ascii

On Wed, Jan 30, 2002 at 10:52:45AM -0000, Matthew Dovey wrote:
> A rich negotiation mechanism is the logical conclusion of the "element
> set" notion you outlined. My fear is that taking on board the "element
> set" idea will be a slippery slope where we either end up with a
> negotiation mechanism or we end up with a messy series of ad hoc
> mechanisms for lots of options which would be better replacing with a
> negotiation mechanism.
>
> I suppose I'm arguing that we either embrace this optional elements
> issue fully or not at all.
>
> Matthew

I understand the abstract opinion, but I am not (currently!)
convinced. To me SRW is not going to get bigger than Z39.50. So
there is a finite upper bound of features that can be considered.
(The upper bound may be largish... :-)

I guess I am not sure what "negotiation" means. It makes it feel like
there is going to be a session. To me one of the goals of SRW is to
enable it to be used in a single request/response situation without
sessions. Helps a lot with load balancing etc. Sessions can be useful,
but they should not be mandated. So I would not want to move towards a
model where you have to send a first negotiation request to a server to
see what it supports before sending the second "real" request. If this
is the intent of "negotiation" then I very much dislike it.

Having a look at the Z39.50 API we implemented (not YAZ etc), then we
have the following additional things over what is already in SRW:
element set names, and whether term highlighting is wanted (via applied
variants). I doubt I would succeed in getting term hilighting into SRW
(I guess I could try :-), so element set names are the only other thing
that we have used overa a wide range of applications we built over the
past 6 years or so. And we use element sets frequently (for performance).

So I would say, yes, adding element sets is another feature.  But I
dont think because we are talking about adding one feature that the
flood gates are going to open. We did, after all, just agree to remove
the response schema removing lots of complexity.  So far I have not
suggested any optional bits (unless the record schema and element set
name can be defaulted by the server).  In that case those values would
be nillable (but the WSDL file stays exactly the same).

The concern you expressed was ending up with a "messy series of ad hoc
mechanisms for lots of options" - what other things out of Z39.50 do
you think are missing for search/present? Or that you think other
people might ask for? Maybe its worth thinking about what we want in
and what we don't want in now. If we agree that Z39.50 is the upper
bound, then its a matter of people having a look through Z39.50 for
features not currently supported and then deciding why those features
are or are not going to be supported. My argument for element sets
(and I would be happy only allowing a single element set name, although
our API allows an array of names) is that they deliver a significant
performance improvement which I think is important in real life
applications.

Alan