Rob,
I will use explain. Not yet using explain does not have anything to do
with XSL but with the following. We use collection descriptions to build
lists of targets. These collection descriptions are searched for as
normal records and should contain the information to inform the user
about a collection and what the access rights are and tell the portal
the baseURL and other relevant information. The user can click a button
and than the record is transformed to a target for searching.
Explain decribes the service and the collection description describes
the collection. In my collection descriptions I combined the collection
information and the service information. When I use explain I still need
the collection description to find the baseURL of the explain record.
And the collection description should contain other Zeerex information
to enable searching. So I need most relevant information already befor
actually accessing the target.
Currently I am thinking of retrieving the explain record when a user
selects it for using the native search fields. If you do not mind I will
use your stylesheet for it.
Theo
>>> [log in to unmask] 8/8/03 1:37:52 nm >>>
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
|