Hi Ed,
On 19/01/11 13:27, Ed Summers wrote:
On Wed, Jan 19, 2011 at 6:28 AM, Richard Jones<rich...@oneoverzero.com> wrote:
We've had a few discussions in the past about "supporting" some formats, and
they always end up pretty divisive. So SWORD is aiming to be totally
agnostic on the point, but it does need to provide the client and server a
mechanism to negotiate over what format they are interchanging. If we can
achieve that, that will be relatively useful in an interoperability setting,
I think, particularly as many SWORD servers (particularly repositories) are
able to create dissemination packages in a large number of formats (see
EPrints export plugins for example).
Would it be too restrictive to require SWORD collections to only
support one package format? This would mean that there MUST be
one and only one sword:acceptPackaging per app:collection in the
service document. I think this would simplify matters significantly
for implementors since:
1) there would no longer be any need for the q attribute on
sword:acceptPackaging, and the requirement to interpret them.
2) X-Packaging header registration, and the need for clients to send
it would go away
2) a client could only retrieve a package in the format it was
deposited in. Does anyone really have an appetite for dynamically
rewriting package formats as part of an HTTP request cycle?
I think that would be overly restrictive, while the above gains are
relatively minimal in the scheme of things.
Also, as per my earlier comment about export plugins in EPrints, you
could easily imagine throwing a known package format into the
repository, and then asking it to give you it back in a variety of
formats that you don't know how to generate yourself.
I guess a better question is: do we have many SWORD implementations
that support POSTing multiple package flavors to the same collection?
Also, I am -1 on SWORD requiring a standard package format. I think it
would be fine to list some preferences, and light-weight, community
driven mechanisms for identifying them, but that's as far as SWORD
should go IMHO.
It's been a long standing complaint against SWORD that despite it being
an "interoperability" standard, you can't even deposit the same package
into DSpace, EPrints and Fedora, let alone other implementations that
weren't funded as part of the original project. From both a practical
point of view and a community perception point of view this has to be
addressed.
We have tried to work around the "standard" package format issue by
adopting an Atom Multipart [1] deposit of an Atom Entry with optional
embedded metadata plus a binary payload which may either be a single
file or if given the Content-Type of application/zip a plain old zip
file with no prescribed internal content. This ought to be satisfactory
because it is not only about the most simple format you could come up
with, but it also leverages the existing semantics of AtomPub, so adding
it is of minimal effort.
http://tools.ietf.org/html/draft-gregorio-atompub-multipart-04
Cheers,
Richard
