Date:         Wed, 30 Jan 2002 09:50:47 +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 LeVan,Ralph on Tue, Jan 29,
              2002 at 03:43:02PM -0500
Content-Type: text/plain; charset=us-ascii

On Tue, Jan 29, 2002 at 03:43:02PM -0500, LeVan,Ralph wrote:
> ...  In the best of all
> worlds, the response is not an XML record with a schema but is a complex
> searchResponse object with a number of data fields in it, one of which is a
> vector of strings, each string containing an XML response record.
>
> If we can't get folks to agree to that, then I can live with a single
> responseSchema and I'll parse the response myself.  (But I'd prefer to let
> SOAP do that for me!)
>
> Ralph

I agree 100%. I think SOAP toolkits should be able handle most of
the request. Personally I think SRW should have its best shot at
producing a useful 'response schema' based on all the Z39.50 knowledge
gained. I do not see the need to put in lots of optional bits. That
is one of the things that makes Z39.50 such a pain to implement - there
are so many optional bits that you might have to worry about because
someone else has used this optional bit but you have used that
optional bit. (No deep criticism intended here - more an observation).

If people really really need a new request, then we can look at
changing the definition. Or adding a new method. However until then,
I would be aiming at keeping it small and simple for the infrastructure.


Element set names to me are an orthogonal issue. I personally can
see the value in element set names. For efficiency, it is useful
to be able to drag back "brief" versions of 20 records for summary
lists. Dragging back the full records can waste a lot of network
traffic. But I am not too stressed either way. I guess it depends
on if the format of the record schema string and how it is standardised.
For example, you *could* define different record schema names for
the full and brief versions, but that feels pretty grungy. So I
would not object to putting in element set names. But I would not
cry if they were not there.


Mind you, I personally would also not mind support for cross database
searching as well. But I remember there were some very strong opinions
against this. I think the argument was along the lines that since all
databases might not be on the one server, the client needs to support
sending multiple query packets anyway. If combinations are common, you
can also define an 'alias' on a server so the server does the distribution
across multiple databases. So I guess I should just close my mouth on
this one. Maybe the point is that we should keep features out that
don't completely solve a problem (such as searching multiple databases
in a single packet), but maybe we should consider features more seriously
if there is no other clean way of supporting the functionality when there
is real benefit in the functionality (and I consider network performance
to be a real benefit).

Alan