Sebastian, I think you are making a key point. The SRU protocol does have
different requirements from SRW.
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.)
http://herbie.bl.uk:9080/cgi-bin/istcg1.cgi?query=roma
http://herbie.bl.uk:9080/cgi-bin/blpcg1.cgi?query=charles%20AND%20dickens%20
AND%20christmas
http://herbie.bl.uk:9080/cgi-bin/copacg1.cgi?query=charles%20AND%20dickens%2
0AND%20christmas
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. (The targets are actually supplied by a SRU/Z39.50
gateway.)
What is the best way of handling this divergence ?. A new URL base protocol
or adapting the existing protocol ?.
Bill
-----Original Message-----
From: Sebastian Hammer [mailto:[log in to unmask]]
Sent: 07 August 2003 13:47
To: [log in to unmask]
Subject: Re: Betr.: Re: xPath in searchRequest
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
requirements.
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? :-)
--Sebastian
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
>
>Theo
>
> >>> [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]>
>http://www.miketaylor.org.uk
>)_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
> http://www.pipedreaming.org.uk/childsplay/
--
Sebastian Hammer, Index Data <http://www.indexdata.dk/>
Ph: +45 3341 0100, Fax: +45 3341 0101
**************************************************************************
Now exhibiting at the British Library Galleries:
Painted Labyrinth : the world of the Lindisfarne Gospels
Until 28 September 2003. Admission Free.
*************************************************************************
The information contained in this e-mail is confidential and may be legally
privileged. It is intended for the addressee(s) only. If you are not the
intended recipient, please delete this e-mail and notify the
[log in to unmask] : The contents of this e-mail must not be disclosed or
copied without the sender's consent.
The statements and opinions expressed in this message are those of the
author and do not necessarily reflect those of the British Library. The
British Library does not take any responsibility for the views of the
author.
*************************************************************************
|
