> 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)

--
Listen to free demos of soundtrack music for film, TV and radio
        http://www.pipedreaming.org.uk/soundtrack/