Hi Ray and others,
Here are my answers to your questions about the SRW "Response Schema". 
(I believe, that my interpretation is basically the same as Alan's').

1) SRW currently supports only one request/response function, i.e. the SRW
"searchRetrieve" operation.

2) The input- and output- parameters of the "searchRetrieve" operation are
defined by only two messages appropriately called "searchRetrieverRequest"
and "searchRetrieveResponse".

3) The current "ZiNG" WSDL prototype definition includes a string-parameter
called "responseSchema" as part of the "searchRetrieveRequest" message.
This parameter was intended to let a SRW client instruct an SRW Server to
respond with an alternative message-format referenced by the
"responseSchema" string (URI).

4) In WSDL it is difficult to specify the use of arbitrary undefined message
(parameter) structures as part of a given Web Service operation (function). 
It is therefore proposed to drop the "responseSchema" parameter from the
"searchRetrieveRequest" message in the "searchRetrieve" operation.

5) The draft SRW WSDL specification, that was presented during the April
2002 ZIG Meeting at OCLC, has been updated.
The revised version is closely aligned with the ZiNG prototype specification
without the "responseSchema" parameter.
The revised SRW WSDL is available here: 

(The revised SRW WDSL has been validated by a couple of standard WSDL tools
including XMLSpy, XMethods and SOAPClient - but not by MS .NET)

Best regards,
Poul Henrik Jørgensen

-----Original Message-----
From: Ray Denenberg [mailto:[log in to unmask]]
Sent: 15. maj 2002 17:27
To: [log in to unmask]
Subject: Re: srw instances -- response schema vs. wsdl

Alan Kent wrote:

> My understanding is that the WSDL file defines the single structure for
> returning records within (for SRW). There was still 1 switch left which
> was to specify the preferred form of XML (eg: Dublin Core vs MODS) for
> the record to be returned in ("record schema"). But there was no need
> for different "response schema"s in SRW.

It's clear that we all agree we don't want multiple response schemas hence
no need for a response schema parameter. I'm still not completely clear why
we need
*any* response schema, and I do understand your point that having multiple
potential record schemas causes a problem for representing this in wsdl.

Is it the case that you simply can't do it, or is it the case that you can,
only by using an encoding form that we didn't want to use?  I suppose I
figure out the answer if I spend a few days reviewing the voluminous
discussion we
had on this, but could someone summarize  please?