At Fri, 29 Sep 2006 09:56:49 +0200,
Janifer Gatenby <[log in to unmask]> wrote:
>
> This question was posed several times.
Thank you kindly for your reply. I am having trouble finding where on
the archive these questions were asked. Again, I realize that it is
very rude to post at so late a date such a fundamental question about
SRU update.
However, I do feel that it would be very helpful if ZNG defined (at
least in addition to the SOAP update) a simple, HTTP-based, update
mechanism. I think that the overwhelming success of SRU over SRW
indicates that developers find HTTP based solutions easier to deal
with than SOAP ones.
> 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.
Yes, this is true. There is no way that HTTP 1.1 will be changed for
SRU. However, there is no reason why you cannot use the following as
responses:
400 Bad Request
X-SRU-Diagnostics: 1. Invalid component: record rejected.
...
400 Bad Request
X-SRU-Diagnostics: 2. Invalid component: component rejected
...
404 Not Found
X-SRU-Diagnostics: 50. Record not found (replacement or delete)
...
In other words, there is no reason that you can’t extend the
granularity of the HTTP response codes with some of your own, as long
as the HTTP response codes are broadly correct.
In addition, the WEBDAV standard defines unilateral extensions to the
HTTP response codes in section 10 of RFC 2518. That is, they are
defined in the context of WEBDAV and not for other HTTP standards, and
so did not have to change the HTTP standard.
> 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.
I don’t see where these features are defined in this draft.
> 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.
There is no reason that PUT cannot return a modified version of what
was sent to the server, or a completely different format, etc. There
is also no reason why POST cannot be used in a simpler way without the
entire SOAP stack of standards.
In other words:
-->
POST /sru
Host: example.org
Content-Type: application/x-xml+dc
<dc>
<title>A document</title>
</dc>
<--
201 Created
X-SRU-Diagnostics: 33. Record schema unacceptable: record converted
Location: http://example.org/records/1
Content-Type: application/x-xml+mods
<mods xmlns="http://www.loc.gov/mods/v3">
<titleInfo>
<title>A document</title>
</titleInfo>
</mods:mods>
Again, thanks for the response.
best,
Erik Hetzner
