> I am getting confused about the objectives of SRW/SRU. I thought it was
> meant as a lightweight web-service based alternative to Z39.50,
> something that should be easy to implement for both servers and
> Now it seems that a new objective creeps in, about administration,
> maintaining, updating and deletion of databases and their content.
> I belive it is better to keep the SRW standard slim and clean, and wait
> for the IT industry to pick it up as it is.
> I think we need to distinguish here between ZING and SRW.
> There was a fairly long debate but the upshot is that we aren't adding
> Update to SRW. There are some nomenclature issues to be ironed out, but
> I hope we don't call it SRW Update (or Update for SRW) etc.
> What we are edging towards is having a family of WebService (lets call
> that ZING, but again nomenclature hasn't been resolved), which include
> SRW and Update (and possibly others). Each of these could stand alone,
> but could also be used together (and combined may eventually provide
> same functionality of Z39.50 over WebService).
> There is a question of whether an Update service is really needed
> that there are other approaches) - I've drafted an initial summary of
> other approaches and how they could relate to the Update service
> discussions at http://www.ceridwen.com/srw/record-update/crud.html
I'm glad to see that I'm not the only one who is a bit confused about
On one hand, I certainly understand the need, somewhere, for an update
function. Such a thing, implemented as a Web Service could come in very
handy. By defining the syntax of an update function semantically it
would be possible to mask much of the technical who-ha required for the
underlying data store. Authentication. Authorization. SQL. A file
system. Etc. At the same time, HTTP PUT functionality has been around
for quite a while, yet it does not seem to be very popular. Maybe the
problem of updating is relatively small compared to search.
If folks are going to create an update service, then as alluded to
above, I don't suggest the service be associated with SRW/U. That
namespace (all puns intended) is already taken. :-)
Finally, I believe the hallmark of successful protocols is elegance
combined with the philosophy of the Unix Way. Do one thing. Do it very
well, and do it simply. I sincerely believe SRW/U satisfy these
As far as adoption by the community goes, I think this community needs
to develop a tool similar to Hussein Suleman's OAI Repository Explorer.
Such a thing will build confidence that folks' SRW/U implementations
Eric Lease Morgan
University Libraries of Notre Dame