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 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. //Ed
