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

Actually, the opposite is true.

To describe SRU you really only need the XML Schema files (the WSDL
decriptions for SRU are of dubious use at best). However, an XML Schema
file can only have one target namespace. As diagnotic has its own
namespace (so that it can be used as a surrogate diagnostic records), it
must remain a separate file. XCQL also has its own namespace as
technically this is the XML schema for CQL so like CQL can stand on its
own outside of SRW. Deprecating XCQL entirely would remove this separate
file though.

At best the XML Schema files can only be reduced to a minimum of two.

A WSDL file can however, contain multiple XML schema files, so both
these files could be contained within a single WSDL file. The reason I
didn't do this, is that for SRU (unlike SRW) the WSDL file is not of
much use, and someone wishing to validate SRU responses (or generate DOM
code from one of the many XML Schema to object language e.g. java
mapping available) would need to cut and paste the XML Schemas out of
such a WSDL before they could begin.

I could do two (or three) schema files for SRU, and a single WSDL file
for SRW, but then the bult of the SRW WSDL file would be a complete copy
of the SRU schema files - any software engineer or computer scientist
worth their salt would immediately think of "imports" at that point...

The reason I split the porttypes WSDL from the bindings WSDL is so that
we can easily have a WSDL file binding SRW to SOAP over SMTP for
asynchronous - this could still be achieved via single WSDL files but
these would be almost identical apart from one line (again a typical
case for modularisation).

The only messy bit in the WSDL schemas is the insistence that SRW must
support an SRU style explain operation and if SRU and SRW are available
they must be on the same endpoint. This makes things messy and requires
hacking the SOAP toolkits. I have argued that we should review this
aspect in the past.

I don't think decision-executives would ever look at the schemas, they
would be just as unlikely to look at the ASN.1 in Z39.50. In fact, few
people ever look at the schemas, in 99% of cases it is the tools which
read the schemas not humans.

Re why we shouldn't drop SRW yet. As Eliot and others have already
pointed out - part of the issue is who the audience is. If you are just
talking about Open Source developers, library/e-journal systems etc.
i.e. the status quo then you are probably right - SRU will be the
winner. If on the other hand you want to extend the outreach to include
more mainstream industrial members (Microsoft, IBM, etc.) then you
certainly shouldn't drop SOAP at the moment.

The other reason for not dropping SOAP yet is are the various WS-*
family extensions which rely on the underlying WebService being SOAP
based, such as WS-Security. I think it more likely to find tools
implementing SAML2/Shibboleth for WebService will assumed SOAP for
example.

Matthew