Date:         Thu, 28 Sep 2006 18:13:31 -0700
Reply-To:     "SRU (Search and Retrieve Via URL) Implementors"
              <[log in to unmask]>
Sender:       "SRU (Search and Retrieve Via URL) Implementors"
              <[log in to unmask]>
From:         Erik Hetzner <[log in to unmask]>
Subject:      Re: New draft of Record Update
Comments: To: "SRU (Search and Retrieve Via URL) Implementors" <[log in to unmask]>
In-Reply-To:  <[log in to unmask]>
Content-Type: text/plain; charset=US-ASCII

At Tue, 26 Sep 2006 17:00:22 -0400,
"Ray Denenberg, Library of Congress" <[log in to unmask]> wrote:
> 
> A new draft of the Record Update protocol has been developed by the SRU
> Editorial Board.
> http://www.loc.gov/standards/sru/record-update
> 
> Please review and comment by October 12.

Hello all,

I know that I am a bit late to this game, but given the great uptake
of SRU (as opposed to the SOAP based SRW), could somebody explain to
me what this solves that could not be solved with pure HTTP? This is
an almost classic problem for:

a) URIs that define a unique record, and perhaps a particular version
of that record.

b) the HTTP verbs define the operations: PUT (replace in this
proposal), POST (create), DELETE (delete).

c) the HTTP response codes define a great number of possible statuses,
including success (200), failure (4xx), delayed (202 Accepted), etc.

d) other response information, if required and it is not possible to
fit into the HTTP headers, can be wrapped around the srw:record
element.

A solution of this sort seems to me to be simpler and easier to
implement, especially for those who have currently implemented SRU but
not SRW.

Best,
Erik Hetzner
--
Erik Hetzner
California Digital Library
510-987-0884