On Fri, Nov 30, 2001 at 05:58:52PM +0100, Theo van Veen wrote:
> Ray,
>
...
> With respect to SRW-U and SRW-R: I would prefer that SRW-U will be a
> minimal requirement and that SRW-R is an extended version of SRW-U.
...
> The only reason I am aware of for using SOAP is to handle input that
> cannot be put in a URL-GET.
I agree with Ralph here (even if I am making different points). If this
is the reason for using SOAP, then do not use SOAP. It is not a suitable
solution for that requirement. SOAP is not a trivial protocol. I agree
with Ralph's point (if I understood it :-) that if you want to support
SOAP and interoperability, then don't think you can define the structure
of a SOAP resposne so you can just remove a wrapper element. SOAP has
all sorts of other constructs such as href/id, mustUnderstand headers,
root element markers, etc which allow the same information to be
encoded in different ways. Literal document encoding might be an
option (I am still a bit ignorant here).
I think the only reason for using SOAP (without document literal encoding
anyway) is if you want to come up with a Z39.50 friendly standard for
SOAP users to use. This leads me to believe even more strongly that
SRW-U and SRW-R should be separate activities. Maybe a part of SRW-U is
a way of coming up with a GET and POST standard (so you can use POST
variables for more complex things if that is what is needed).
I guess I really should read up on literal document encoding in SOAP.
Something for the issues list :-)
Alan
|