I get the impression that part of the difference of perception here comes
from the fact that while SRU and SRW are supposed to be different but
equivalent syntactic expressions of the same semantics, or abstract
protocol, in fact the two protocols are faced with subtly different
The way I understand it, a large part of the appeal of SRU is the ability
to build fairly "thin" clients, that execute in the browser using whatever
logic and formatting tools available there. I can see how putting some
creative interpretations on the server-side there can significantly
simplify the task of building those clients.
SRW, conversely, is meant to fill the same shoes as Z39.50, only hopefully
better. Here, we have learnt through a decade of bitter experience that
creative servers are not good for anyone, and the profiles (ie. Bath and
co.) all emphasise the importance of rigorously phrased and interpreted
queries. We're trying to reduce Z39.50 complexity, but we can't afford to
compromise on the control -- if anything, we have to make it *tighter*,
recognising that the freedom left to Z servers that are not governed by
rules (ie. profiles) makes them very nearly useless.
So, having made the decision to try to meet these differing (and, I say,
conflicting) requirements with SRW/U, how do we minimize the damage? Do we
need a flag in the request to indicate that the server *is* allowed
creativity in the response? :-)
At 14:19 07-08-2003 +0200, Theo van Veen wrote:
>I get the impression to be misunderstood. When I ask for number 5 nails
>I do NOT want to receive number 6 nails and I do NOT want the seller
>say to me: "error, leave the store and ask for something else". I want
>the seller tell me "we do not have that but here is a list of the type
>of nails we have and how much we have in store" but the analogy with the
>original issue is not perfect
> >>> [log in to unmask] 8/7/03 1:16:16 nm >>>
> > Date: Thu, 7 Aug 2003 09:23:57 +0100
> > From: "Matthew J. Dovey" <[log in to unmask]>
> > I'm trying to recall whether we said anything about returning
> > diagnostics with records. i.e. in Theo's case he could return his
> > captioned records but also a diagnostic to the effect that XPath
> > isn't supported.
> > ditto from XML versus escaped - i.e. return what you can but also
> > return an error diagnostic.]
>This is a bad idea for the reasons Rob's already pointed out.
>My client: Find "fruit" and give me brief summaries of the first ten
>records according to this XPath, please.
>Your server: Certainly, sir! Here are ten 50Mb EAD records; oh, and
>by the way, I couldn't do that XPath bit you asked me about. Enjoy
>your link saturation, sir!
> > in our blasted nail example - this would be akin to the seller
> > handing over a bag of size six nails and saying "we have no size 5
> > will these do?"
>Not really. It's more like saying "we have no size 5, you MUST take
>these size 3,546 instead, but you're allowed to throw them away as
>soon as you get home". If this is Theo's idea of "interoperability"
>then we really are using the word in two totally different ways.
> > Personally, I think I'd prefer to get a diagnostic xor what I asked
> > for.
>Yes! Then the dialogue goes --
>client: I'd like a box of number 5 nails, please.
>server: Sorry, sir, we're fresh out of them.
>client: In that case, I'll have number 7s.
>server: Certainly, sir: here you are!
>[hands them over]
>I actually think hardware-store analogies are _very_ helpful in
>thinking through these things, sorry Matthew!
>/o ) \/ Mike Taylor <[log in to unmask]>
>)_v__/\ "You took the words right out of my mouth / It must have
> been while you were kissing me" -- Meatloaf, _You Took The
> Words ..._
>Listen to my wife's new CD of kids' music, _Child's Play_, at
Sebastian Hammer, Index Data <http://www.indexdata.dk/>
Ph: +45 3341 0100, Fax: +45 3341 0101