> Then have we made a horrible, horrible mistake in the way 
> we've defined SRW?  It it basically don't work with existing 
> toolkits, do we need to throw it all up in the air and make 
> 2.0 that uses rpc/encoded?

<sigh> How did I know you would say that...

There is an industry accepted profile - WS-I (see http://www.ws-i.org).
All the major WebService players are adopting this profile, all the
major toolkit manufacturers are adopting this profile. *This* is the
profile to adopt if you are doing WebServices. SRW 1.1 is WS-I
compliant.

The reason WS-I specifed doc/lit rather than rpc/encoded was because of
interoperability issues - getting two toolkits to work together using
rpc/encoded was a real headache.

Some of the older toolkits (and toolkits which haven't been maintained)
will have trouble with doc/lit - but all of the major toolkits now (or
shortly will) support WS-I thus improving interoperability.

However, why not take a few steps backwards and use RPC/Encoded to
support the out of date toolkits - that way we can ensure
interoperability problems with newer toolkits, ensure complete lack of
adoption by the wider WebService community (since it wo'n't be WS-I
compliant), ensure that it can't be adopted up by UK government funded
projects (that includes JISC and academic funded projects) since they
are supposed to follow the e-GIF framework which states WS-I as a
requirement, and I suspect US government projects too.
 
> There doesn't seem to be much point in having superseded 
> Z39.50 with a "friendly" web-service protocol if the barrier 
> to implementation remains at the same height because none of 
> the web-service toolkits can implement SRW.

Apart from .Net, Axis, hopefully Mono now I've fixed the bugs...

The problem toolkit appears to the the Perl one (and apparently the
version available about 12 months ago at that).

Matthew