I actually think many of us are out there getting pretty good take-up of
SRU, convincing people that it's certainly the looking in the right
direction. It's interesting to see LOM and spatial searching listed as
two sets of requirements being investigated, both of which have deployed
SRU solutions in use today. We've got buy-in from a large central UK
gov't aggregator service too thats based on SRU. You just need time for
the services that have been developed and deployed to start to surface
in every day use.

What, IMNSHO, _undermines_ efforts to have SRU adopted (Rather than
improve it's takeup) is the uncertainty created by a _base_ standard
thats never left still long enough to gain any traction. With the
original SRU discussions I think we were very careful to have
alterations not break existing implementations (Indeed this was the case
with Z3950 for the most part), and that message was pretty clear I felt.
I'm not getting that feeling with these proposals, and thats a bit of a
worry.

Also, i think it might be a bit careless to say that Z3950's
interoperability problems were caused by ASN.1 and BER (ssh seems to be
doing just fine from an interoperability perspective). I'm sure that the
majority of interoperability problems are affected by the presence of a
good service description document. I have to admit that I (Very
personally) always felt ZeeRex wasn't abstract enough and at a certain
level it looks like Z3950 and SRU/W structures were just tagged under
some container tag. So, sure, lets discuss the "Description Language"
but I'm not sure the context of rushing something through like this
(Thats how it feels) is the best approach.

Have to say that I'm with mike in the "If it 'aint broke don't fix it"
camp. if we're starting with whats wrong with SRU, then I'm all up for a
discussion of why LOM or spatial searching doesn't work currently and
what we might need to do.

Oh, and SRU doesn't use SOAP? Well, none of the systems I've seen or
implemented?

Ian.


On Fri, 2008-08-29 at 15:58 +0100, Ashley Sanders wrote:
> Mike Taylor wrote:
> 
> > Really?  It's hard for me to see how this is a good idea.  Surely our
> > problem at the moment is how to improve take-up of SRU as it currently
> > exists -- 
> 
> What do you think might improve the take-up of SRU? Or put another way,
> why do you think people are slow/reluctant to use SRU?
> 
> > Not to mention bringing the
> > resulting protocol yet closer to the Z39.50 it was deliberately
> > designed to simplify.
> 
> Is SRU simpler than Z39.50? Both use obscure transports (SOAP v. ASN1 & 
> BER) that have/had notorious interoperability problems. Both come with
> an obscure query language that will be pretty daunting to the newcomer.
> 
> If you want to simplify z39.50 I think you can go a whole lot further
> than SRU. And in the real world people do go a whole lot further than
> SRU and go and create their own interfaces that hide behind urls that:
> 
>     o) may or may not be HTML form driven
>     o) spit out a variety of stuff including HTML and XML.
> 
> Which is where the so-called 'Description Language' comes in.
> 
> Ashley.