---------- Forwarded message ---------- From: Richard Jones <rich...@oneoverzero.com> Date: 20 January 2011 06:26 Subject: Re: content negotiating for package formats To: Ed Summers <e...@pobox.com> Cc: techadvisorypa...@swordapp.org
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 ------------------------------------------------------------------------------ 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
