---------- Forwarded message ---------- From: Julie Allinson <julie.allin...@york.ac.uk> Date: 21 January 2011 07:11 Subject: Re: content negotiating for package formats To: Richard Jones <rich...@oneoverzero.com> Cc: Ed Summers <e...@pobox.com>, techadvisorypa...@swordapp.org
On 19/01/2011 17:26, Richard Jones wrote: > > 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 I might be talking nonsense here, but is this something that could support 'graceful' behaviour ... one thing I noticed in testing was that EPrints will accept a METS package with epdcx but the deposit fails if there is any other metadata instead of or in addition to the epdcx embedded in the METS doc. I'm not criticising EPrints or advocating METS but it struck me that if there is a package that could be deposited knowing that it will succeed and that you could stuff all kinds of things into it which the repository will either know what to do with and do that (unpack etc.) or simply accept and store? ... so for the EPrints case, you might need a new export plug, but in the meantime you could still be making deposits. Julie > > Cheers, > > Richard > > -- Julie Allinson<julie.allin...@york.ac.uk> Digital Library Manager University Library& Archives, J.B. Morrell Library University of York, Heslington, York, YO10 5DD, UK tel: ++44 (0) 1904 324083 skype: j.allinson web: http://tinyurl.com/dcd6a5 disclaimer: http://www.york.ac.uk/docs/disclaimer/email.htm -- ------------------------------------------------------------------------------ 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
