On 19 Jan 2011, at 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 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.
Agreed; there is a distinction between what the spec must address, and what the community of implementers has to agree on outside the spec to make it work. > > //Ed
smime.p7s
Description: S/MIME cryptographic signature
