For the record, there are several SRW clients searching LC.
I have recently corresponded with a new implementor for
several weeks and they are now up and running.
My point is that they _are_ out there. They're the "bold
and the brave" perhaps, but they're out there. Don't
make them feel that they've made a "wrong turn" on the
Information Super Highway.
On Fri, 1 Jul 2005, Mike Taylor wrote:
> > Date: Fri, 1 Jul 2005 11:54:36 +0000
> > From: Rob Sanderson <[log in to unmask]>
> >>> Learning from OAI's success
> >>> [...]
> >>> 1. a well-defined problem statement -
> >> My contention is that much of the perceived complexity, which
> >> requires the multiplicity of documents, is down to SRW (as opposed
> >> to SRU). I draw attention particularly to the affect that the WSDL
> >> file for SRW requires SIX other schema files.
> > That's a side effect of how Matthew has structured the WSDL. It
> > could be combined into one file, I'm fairly sure.
> OK. But it's still a big ol' mess of schemas and WSDLs and suchlike.
> My feeling (could be wrong) is that it'll be pretty easy to
> consolidate all you need for SRU into a single, simple document; but
> next to impossible to do so for SRW. ("Consolidate" here means more
> than just "concatenate" :-)
> > And even getting rid of SRW wouldn't (necessarily) get rid of the
> > WSDL, as non SOAP web service infrastructures can still use the
> > specifications to turn the response into objects for processing.
> _Can_ use it, yes; but don't have to (and, in practice, won't).
> >> If we focussed exclusively on the URL-based version of our
> >> protocol, things would simplify remarkably. In particular, we
> >> could then write a single document that avoids abstractions and is
> >> replete with examples.
> > So while I disagree with the arguments regarding WSDL, I'm hard
> > pressed at this stage to disagree with this statement.
> > Overwhelmingly the interest has been in SRU over SRW, despite
> > industry claims of the magnificence and ubiquity of SOAP.
> Yes -- to my surprise as much as anyone's. For the reasons you list
> below, SRW is still in many ways the better technology of the two; but
> those advantages are significantly outweighed by the market momentum
> of SRU (and its simplicity).
> > Here's my very poor devil's advocate response as to why we need SRW:
> > * Request extensions in SRU are greatly inferior to their SRW
> > counterparts, due to the completely flat nature of the URL parameters,
> > as opposed to arbitrarily complex XML. Secondly due to the ridiculous
> > namespace hacks needed to try and prevent ambiguity between different
> > extensions.
> > * Relatedly, if there is a requirement in the future for structured
> > request parameters at the base level (eg we want to migrate a structured
> > extension into the protocol proper) we have the same problem.
> > * The SOAP structures allow for network related issues to be dealt with
> > outside of the main application area, for example routing requests,
> > authentication and so forth.
> These are all good and strong reasons to prefer SRW to SRU
> technically; but they don't really impinge at all on the decisions we
> need to make at the moment, since as we can see no-one is taking
> advantage of those SRW features, they're all implementing SRU instead.
> Will anyone else speak up for SRW?
> _/|_ ___________________________________________________________________
> /o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
> )_v__/\ "Just another coffin on its way down the Emerald Aisle" --
> Marillion, "Forgotten Sons" (about the Northern Ireland conflict)
Larry E. Dixson Internet: [log in to unmask]
Network Development and MARC
Standards Office, LA327
Library of Congress Telephone: (202) 707-5807
Washington, D.C. 20540-4402 Fax: (202) 707-0115