I think there may be an interaction between this discussion and current discussion of Research Objects; cf.
http://eprints.ecs.soton.ac.uk/21587/ http://www.wf4ever-project.org/wiki/display/docs/Data+packages+in+ADMIRAL Quite coincidentally, I'm also in current email discussion with Dave Crocker (probably best known for RFC822) about an all-new UTF-8 clean message format for email. I'm not sure if any of this is relevant... #g -- Graham Triggs wrote: > On 19 January 2011 09:49, Scott Wilson <scott.bradley.wil...@gmail.com > <mailto:scott.bradley.wil...@gmail.com>> wrote: > > I think its time to take a step backwards here. > > The "packaging problem" identified by the SWORD project was not that > SWORD or AtomPub have a problem with POSTing packaged content formats. > > The problem is that implementations of SWORD in the academic > repositories community use - needlessly, IMHO - diverse incompatible > formats, especially of metadata within a package. > > I don't see that adding any number of HTTP headers is going to > improve interoperability while this remains the case. If nothing > else, I would expect implementations to largely ignore any such > headers sent by the client and look inside the package to try and > figure out what it is and if it can support it. The headers just > provide more opportunities for client error. > > I would suggest SWORD is completely agnostic on the subject of > packaged content formats, but that the SWORD implementation > community make a concerted effort to identify and support a common > core of packaging and metadata formats so that there is practical > on-the-ground interoperability with a reliable default format for > client implementations to support out-of-the-box. > > > I want to agree on having a standard package, but there are issues with > saying that. The most obvious is how that sits with the current use of > SWORD. > > But there is also the situation that repositories are used in different > ways, have different features (that reflect in their content) and > contain a wide range of different materials. > > We could agree on and define a profile that works in the most general > way for a set of use cases / content types. But that would still leave > it up to us/others to define other profiles that would be used in those > other scenarios. > > I don't think you can ever get away from a degree of content > negotiation, but it doesn't necessarily need to be as complex as the > scenarios outlined depending on what agreements you can have for common > formats in common cases. > > G ------------------------------------------------------------------------------ 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
