---------- Forwarded message ---------- From: Scott Wilson <scott.bradley.wil...@gmail.com> Date: 20 January 2011 02:37 Subject: Re: content negotiating for package formats To: Ed Summers <e...@pobox.com> Cc: techadvisorypa...@swordapp.org
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 ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
