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.
Larry

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.
>
> Interesting.
>
> 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