This question was posed several times.  Update mechanisms like WebDav that use HTTP PUT, POST and DELETE rely on HTTP diagnostics and it seems quite an effort to get influence to create new diagnostics here.  HTTP diagnostics are too limited for updating metadata.  Most update mechanisms are focussed on document updating and sharing documents.  They miss elmenets that are important to metadata catalogues and repositories such as aligning control numbers, authority linking, linking multiple language versions etc.  In addition, the focus is on the client having update power, whereas with SRU update, the power is more or less shared.  The client is making a suggestion and the server ingests it as best suits the database, hence the need for interactive diagnostics and the employment of POST rather than the more specific PUT, etc.
 
Janifer Gatenby
OCLC PICA

________________________________

From: SRU (Search and Retrieve Via URL) Implementors on behalf of Erik Hetzner
Sent: Fri 9/29/2006 3:13 AM
To: [log in to unmask]
Subject: Re: New draft of Record Update



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