I don't agree. As long as SOAP is not a standard part of webbrowsers SRU
is a very powerful mechanism for buidling realistic systems because of
the integration at the level of the workstation and the browser
certainly is the best place for it. The fact that it can be applied by a
ten-minute hack is just a negative way of saying that it has a low
barrier for implementation.
The statement:
"we have all the requests for
just-do-_something_-it-doesn't-matter-what functionality in servers --
all coming from from SRU-oriented developers who are working in a
constricted environment that doesn't allow them to build flexible or
intelligent clients"
gives a wrong impression. Only the request records being in XML had to
do with the use of SRU. Other requests for improving the standard would
also have been done without SRU. Most of my own requests do not reflect
the weakness of SRU but my different way of thinking with respect to
search and retrieval. This different way of thinking is that I prefer
more information being sent by the server (not being creative)  to
minimize the need for dialogues between client and server and that I
prefer specification of rules above values. This applies to both SRU and
SRW.

Theo


>>> [log in to unmask] 8/8/03 12:44:34 nm >>>
> Date: Fri, 8 Aug 2003 09:42:44 +0100
> From: "Oldroyd, Bill" <[log in to unmask]>
>
> Sebastian, I think you are making a key point. The SRU protocol does
> have different requirements from SRW.

Yes - this is becoming increasingly clear.  Maybe it's time to drop
appealing but ultimately unsustainable fiction that SRW and SRU are
the same protocol running on different transports.  Or maybe we should
go the other way, reinforce that notion and Make It So -- though that
would mean disappointing our more SRU-o-centric members in terms of
what they can achieve.

> As an example here is an "SRU" thin client talking to 3 "SRU"
> services. (You need IE 5.5+ or Mozilla Firebird to see them work.
> Perhaps Safari will work too - I would like to know as I don't have
> access to an Apple OS X machine.)
> [...]
> The client comprises two XSLT scripts, one for brief and one for
> full records. To talk to a number of SRU targets, and to keep the
> scripts and the functionality simple, the SRW:searchRetrieveResponse
> includes details of each target. This is because it is surely easy
> for the target to include this information, and it eliminates any
> problems in looking for this information elsewhere.

This kind of talk always bothers me.  What we effective have here
seems to be a ten-minute hack grown bloated and cancerous.  And
instead of cutting out the cancer, we're worrying about how to make
the environment more cancer-friends.  (Apologies if this analogy is
tad gross ... at least it's not a hardware store :-)

It's easy to understand the appeal of SRU ... you immediately think,
"Hey, we just un an XSLT engine in the browser, and *bingo*, a whole
application!"  That's great for prototyping, but as soon as you start
trying to build it up into a realistic system -- one that can be used
to do anything more than demos -- you quickly start running into
walls.

The browser is just the wrong place for anything more than the most
basic programming.  The whole point of the web is that anyone can use
whatever browser or server they want so long as it speaks the
protocol; but that model breaks as soon as we start trying to wedge
functionality into the browser: hence statements like "You need IE
5.5+ or Mozilla Firebird to see them work."  As if anyone's going to
go and download and learn a new browser just to see one site!

And because client-side programming in the browser is so limited (it's
trivial to do easy things but impossible to do anything more), we have
all the requests for just-do-_something_-it-doesn't-matter-what
functionality in servers -- all coming from from SRU-oriented
developers who are working in a constricted environment that doesn't
allow them to build flexible or intelligent clients.

> What is the best way of handling this divergence ?. A new URL base
> protocol or adapting the existing protocol ?.

Maybe a formal fork is the best way forward.  Those who insist on
trying to do real work with SRU should probably have the option of
changing it to make it less unsuitable for their needs without having
to drag the (to them) dead-weight bulk of SRW around with them; and
those who need to build real systems can concentrate on getting SRW
right without worrying about breaking the fragile bough fronm which
SRU hangs.

Rant ends.  Thanks for listening.

(oh, and: Bill and Theo, I'm sure you realise that this is by no means
meant to be a personal attack.)

 _/|_
_______________________________________________________________
/o ) \/  Mike Taylor  <[log in to unmask]>
http://www.miketaylor.org.uk
)_v__/\  "There was a time when nostalgia wasn't so popular.
         Those were the days" -- Ian Ridley, writing in the _Observer_

--
Listen to my wife's new CD of kids' music, _Child's Play_, at
        http://www.pipedreaming.org.uk/childsplay/