I am not trying to just throw things into SRU except from the point of view
of prototyping ideas. That's why I put "SRU". The specific point I am trying
to pursue is that the SRU response could be extended to include data that
would make it much easier to implement a stateless URL based search.
This is why I asked the question, should we develop SRU or should we develop
another URL based protocol that is derived from SRW/SRU. Judging by the
response, I think people would prefer the second option. Perhaps we could
call it search and retrieve using REST, as I think that is what I am trying
to achieve.
I know there are lots of difficulties with this approach such as the browser
type, but the browser population is always changing in the right direction
and the same XSL processing can be done server-side if necessary.
Rob, I didn't use your Python interface to Cheshire because I needed to do
something quickly to demonstrate a possibility, but I would very much like
to cooperate and if possible re-use your work when we have to implement a
live system. By using Zoom it is possible to write a simple gateway with a
very small script.
Bill
-----Original Message-----
From: Robert Sanderson [mailto:[log in to unmask]]
Sent: 08 August 2003 12:06
To: [log in to unmask]
Subject: SRW and SRU compliance
As everyone (or at least multiple people on the list already) seems to be
just throwing in their own bits to the response and request for SRU
regardless of what the protocol says, hence breaking interoperability, I
begin to agree (very sadly) with Sebastian that SRU needs a 'creative'
parameter.
If the creative parameter is not given, then only the official protocol is
used rather than all of the extra things that the server has added for its
own convenience. If you send the creative parameter then you take your
chances with what you get back. If you send back the 'creative' stuff
without being asked, you are -not- SRU compliant.
Or as Mike suggests we can split SRU and SRW completely. I'm not
especially interested in a lax, uninteroperable, XML over HTTP 'protocol',
so would be quite happy to just work with SRW. However SRU is useful for a
quick demonstration of a server, rather than a less impressive or
significantly more work SOAP demo.
Or, even better and my personal favourite, people could just stick to the
protocol! If they feel that something is required in the protocol, then
they discuss it on the list rather than just going ahead and putting it
in. But is this being overly optimistic? Is the list open yet?
Bill, can I ask why (as you're using Cheshire for the database) you didn't
just use my (pretty much complete and more importantly compliant) SRW/SRU
implementation? Especially as its written in Python like your own. I
have a copy running on the ISTC database we have here in Liverpool even.
Rob
--
,'/:. 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
**************************************************************************
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.
*************************************************************************
|
