> Date: Fri, 8 Aug 2003 14:15:52 +0200
> From: Theo van Veen <[log in to unmask]>
>
> I don't agree.

:-)

Hi, Theo. I afraid I don't think there's going to be any way through
this discussion that makes us both happy. I fear we're going to have
to fight to the death :-)

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

SOAP is only a tiny part of the issue here. That would give you a
somewhat more robust communication layer between client and server,
but it would still need you needing to construct your actual
application logic within the framework of an environment patently
unsuited to that role. I think every one of us who has built real
Z39.50-based applications has discovered that the Z39.50 comms layer
is only a small part of the whole business of creating an IR
application; that's going to be just as true when the comms layer is
built on XML/HTTP instead of BER.

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

I'm sorry, I didn't make myself clear here. I didn't intend the word
"hack" as a perjorative; quite the opposite, I meant it in the classic
hackerly sense of "a clever trick". Yes SRU's very, very low barrier
of implementaton is a big advantage. The problem arises, as I've
pointed out, when you try to make your implementation do anything
other than demos.

To use the example that motivated the discussion, here's what a
sensible exchange might look like between an SRW client and server
where the server can't do XPath element selection:

Client: Find these records and give me the first ten summarised by the
        XPath expression "/foo/bar[@baz='quux']"
Server: Sorry, I don't do XPath.
Client: OK, then, give me regular Dublin Core summaries. [Note to
        self: I'll remember this for next time and not ask this server
        for XPath element-selection again.]
Server: Sure thing: here you go. Have a nice day, now, y'all.

Why can't your SRU client do this? Presumably because it's hard to
fit the backing-off logic into the client side. It's not really a
limitation of SRU at all, but of your application platform. If it
weren't so, you wouldn't have been trying to get people to accept the
fuzzy semantics whereby the server's initial response is "I can't do
XPath, but here's something I prepared earlier". In other words, the
motivation for allowing the server to do this horrible thing is that
you want to make it possivlw to build truly trivial clients; and the
only reason that's necessary is because you're insisting on building
those clients in a trivial environment, the browser.

We shouldn't -- I would go so far as to say _must_ not -- allow the
cleanliness and rigour of the protocol to be compromised by the
deficiciencies of one particular client-side environment.

Now then -- shall we arm-wrestle for it? :-)

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

But it's true!

 _/|_ _______________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ If God hadn't meant us to eat, he'd have made us
         photosynthesise.

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