Ashley Sanders writes:
 > > 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?

Fragmentation.  Too many choices.  Adding yet another (or two more)
can only make that problem worse.  Where we _should_ have got to be
now is that anyone wanting to do semantically rigorous searching
across the Internet can quickly discover that SRU is The Right
Answer.  But we are a long, long way from that goal, and it's
questionable whether we're even converging on it.  Interoperability
remains as elusive a dream as it was when SRU was first suggested.
(More elusive, actually: at least Z39.50 had part of the field to
itself back in those heady days.)

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

Really?  I know that ASN.1 and BER are not everyone's cup of tea, but
I've seen _very_ few interoperability problems at the transport
layer.  What Z39.50 interoperability problems I've seen have pretty
much all been at the service level.

Can't say the same for SOAP, of course.

 > Both come with an obscure query language that will be pretty
 > daunting to the newcomer.

I suggest you go back and re-read the first few pages of
	http://zing.z3950.org/cql/intro.html
:-)  There is nothing there to daunt the _newcomer_.  For experts, of
course, there is plenty more to get your teeth into, but none of that
prevents
	author=kernighan and title=programming
from doing what you expect.

 > If you want to simplify z39.50 I think you can go a whole lot
 > further than SRU.

But I don't.  What we're seeing with SRU compared to Z39.50 is
_exactly_ what happened to XML with respect to SGML: conceived as a
lighter, simpler version of its antecedent with all the extraneous
extra complexity stripped away, it has inexorably increased in
complexity until matching and finally surpassing the older standard.
The lesson here is that if you want to do more than unfielded
let-the-server-do-the-best-it-can-whatever-that-is text search, then
you _do_ need all that complexity -- which, it turns out, was in
Z39.50 for good reason.

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

And for people who want to do that kind of thing, there is
OpenSearch.  Good luck to them.

 _/|_	 ___________________________________________________________________
/o ) \/  Mike Taylor    <[log in to unmask]>    http://www.miketaylor.org.uk
)_v__/\  "There's no getting around it: to awesomely, boldy lead in an
	 authentic way, you must be authentically awesome.  There's no
	 room for deception" -- Brant Hansen, _The 417 Rules of Awesomely
	 Bold Leadership_