> 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
> * 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)
Listen to free demos of soundtrack music for film, TV and radio