Date:Tue, 29 Jan 2002 18:35:46 +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 Tue, Jan 29,
2002 at 12:57:09AM -0000
Content-Type:text/plain; charset=us-ascii
On Tue, Jan 29, 2002 at 12:57:09AM -0000, Matthew Dovey wrote:
> Yep - that was the deliberate error!
>
> Attached are some with a few corrections to the namespaces...
>
> Matthew
The penny finally dropped as to what a response schema is.
The idea is to allow a client to change the definition of
the data structure being sent back in response to a query.
This may make sense with SRU (URL based requests), but I
would argue does not make sense with SRW/SOAP/WSDL files.
For a SOAP toolkit to be useful, its got to be given the WSDL
file which includes the structure of the response packet.
I think that SRW should have a single WSDL file with a single
hard coded response schema built into the defintion. Toolkits
can then generate the APIs etc for it. Does anyone (with SOAP)
have need to be able to change the response schema?
I guess it boils down to do you want the response to be an
XML document that the application parses, or a WSDL file that
a SOAP toolkit can turn into programming language data structures.
I personally prefer the latter, in which case response schema
would have to be one of an enumerated list of choices. Personally
I would rather only have one and be done with it. I see benefit
in allowing different record schemas, but don't see the benefit
in different response schemas.
Can someone explain to me why people want them with SOAP?
Can they be removed? (that is, have exactly one response
schema - no way to change it).
I find comparing to ASN.1 useful. I dislike EXTERNAL's in
ASN.1. Sometimes they are good, but give people too many
choices and it makes it harder to use while reducing
interoperability. EXTERNAL for the record contents seems
fine. But I would avoid EXTERNALs for as much as possible
everything else.
But feel free to have a different opinion! :-)
Alan