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

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.


>  Fine for computer scientists, not so
> fine for software engineers, even less fine for decision-making
> executives.

I would reverse the first two.  Fine for software engineers as they have
WSDL compilers.  Not so fine for computer scientists who want to
understand what's going on, rather than just make an application that
works.  Decision makers shouldn't have to look at WSDL anyway.


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

My suggestion is to reformulate the documentation in terms of SRU, and I
guess that it's my job to do that :|, and provide an annex for how to do
SRW if that is more appropriate for some business model or internal
implementation strategy.

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.

* The industry still likes web services, and they may become a lot more
prevalent than they are now. [Which doesn't mean that SOAP may become
more prevalent]

None of which are killer arguments.

The main advantage of SOAP originally (IMO) was that you didn't need the
WSDL as all of the information as to serialisation was carried inline as
type attributes (etc).  However the WSI group pretty much killed that
dead in their recommendation of doc/literal rather than RPC.  Now it's
just easier and faster to use regular document parsing than XML
deserialisation.


-- Rob