When we first discussed Update some time ago, I did a quick summary of
how it would look mapped to various alternatives to SOAP (REST, ATOM,
WS-Transfer, WSRF) - the summaries and pros/cons can be found at
http://www.ceridwen.com/srw/record-update/crud.html

Matthew

> -----Original Message-----
> From: SRU (Search and Retrieve Via URL) Implementors
> [mailto:[log in to unmask]] On Behalf Of Edward Summers
> Sent: 29 September 2006 02:51
> To: [log in to unmask]
> Subject: Re: New draft of Record Update
> 
> On Sep 28, 2006, at 9:13 PM, Erik Hetzner wrote:
> > 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.
> 
> I must admit I find this sort of RESTful api much more compelling--
> especially given the similar approach taken with the Atom-Publishing-
> Protocol.
> 
> <heresy>
> I know that Record-Update has been in the works for a bit, and that
APP
> is relatively new. Nevertheless, have the authors of Record- Update
> actually looked at existing standards such as APP for doing this sort
> of record updating over HTTP?
> 
> I'm wondering if creating another niche standard only used by the
> library world is actually doing anyone in said world that much of a
> service in the long run.
> </heresy>
> 
> Erik, thanks for your honest response...I'm glad I'm not totally
alone.
> 
> //Ed