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
