Some of the issues that Bill has 'solved' by adding in new fields, are my
fault I will admit. We need to sit down and document the possible values
for types of <link> in Zeerex.
(As well as finalising a character set element!)
The issue appears to be that Theo and Bill want to just use XSL to do
their display work in a browser and hence don't want to use Explain for
what it was designed for. At least that's the feeling I get.
Suggestions:
* Put your client into a frameset with one frame. Use the DOM code in the
browser to store semi-persistently the information from the Zeerex file
in the frameset, and display the results in the single frame using
Javascript.
* Change the XSLT to include this information. (This is what I do.)
Then in your server change the line that says which XSL file to use to
be database dependant. Not very hard as you already have the information
(obviously or you couldn't put it in the response).
This change could be done dynamically if the XSL file is generated via
(trivial) CGI.
To step through the out-of-protocol elements:
<SRW:nextRecordPosition>http://herbie.bl.uk:9080/cgi-bin/istcg1.cgi?query=21</SRW:nextRecordPosition>
This is wrong. It's an integer, not a URL, see spec.
<SRW:nextRecordURI>http://herbie.bl.uk:9080/cgi-bin/istcg1.cgi?query=roma&recordSchema=dc_record&startRecord=21&maximumRecords=20</SRW:nextRecordURI>
I don't see any need for this?
<SRW:databaseURI>http://herbie.bl.uk:9080/cgi-bin/istcg1.cgi</SRW:databaseURI>
This is generatable from Zeerex.
<SRW:databaseBriefTitle>ISTC</SRW:databaseBriefTitle>
Do we need a brief title element for Zeerex?
<SRW:databaseFullTitle>Incunabula Short Title Catalogue</SRW:databaseFullTitle>
This is (trivially) generatable from Zeerex.
<SRW:databaseLogo>http://herbie.bl.uk:9080/images/logo68web.gif</SRW:databaseLogo>
<SRW:databaseHelp>http://herbie.bl.uk:9080/databases/istc.html</SRW:databaseHelp>
Two pretty important link types that need to go into the Zeerex
documentation.
<SRW:recordSchema> dc_record </SRW:recordSchema>
This is also just wrong. It should be the URI, see spec.
<SRW:recordXML> ...
Although this is still in flux, I believe that it needed to be
requested explicitly via recordPacking?
<SRW:recordPosition> 2 </SRW:recordPosition>
<SRW:echoedRequest>
These come at the end of their respective parent elements.
Rob
On Fri, 8 Aug 2003, Mike Taylor wrote:
> > 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/
>
--
,'/:. Dr Robert Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: telnet: nebmedes.o-r-g.org 7777
____/:::::::::::::. WWW: http://nebmedes.o-r-g.org:8000/
I L L U M I N A T I
|
