[Historical note] FWIW, the original work on content negotiation was intended to work in both push and pull environments.
Cf. http://tools.ietf.org/html/rfc2703 One of the things I was trying to avoid was the asymmetric stance w.r.t. sender and receiver of HTTP TCN described in http://tools.ietf.org/html/rfc2295 (both of whose authors were also involved to greater or lesser extent in the media features work). #g -- Richard Jones wrote: > > > On 19/01/11 10:16, Scott Wilson wrote: >> On 19 Jan 2011, at 10:05, Ian Stuart wrote: >> >>> On 19/01/11 09:49, Scott Wilson wrote: >>>> 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. >>> Bearing in mind that I have my tongue embedded firmly in my cheek >>> here... >> >> Oh good! >> >>> I have an excellent content package that will either work with binary >>> data directly included or passed-by-reference, and I am working on >>> Importers for DSpace& EPrints as we speak... as outputs of the OA-RJ >>> Broker work. >> >> I suggest we standardise on a really crappy packaging format with >> almost zero features, combined with a totally inadequate metadata >> schema. At least that way it might actually work.* >> > > I think we're talking slightly cross-purposes here. The problem with > the content negotiation is in when the client /retrieves/ its content > from the sword server, not when it deposits it. > > From a deposit point of view we have the acceptPackaging field in the > service document, which tells the client what formats the server will > support the deposit of, and there is the (X-)Packaging header which > tells the server what the client has given them. The default > (standard?) format that we're recommending for SWORD is a plain old zip > file, optionally augmented with dc embedded in an atom entry sent along > with it, which is very much in-line with the AtomPub spec (and also fits > your criteria above :) ) > > The problem is when the client is trying to retrieve content from the > server, and wants to ask for it in a particular format via content > negotiation. At the moment, there is no provision in HTTP Accept- > headers to ask the server for a METS package. > > 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). > > I don't want us to decide, therefore, on a package format, but on a > mechanism by which a client and server can get together and negotiate > one for themselves. > > Cheers, > > Richard > >>> On a serious note: yes - the transport mechanism should be agnostic >>> to the content... unless one wants to define a content transfer >>> mechanism rather than a transport mechanism :) >>> >>> -- >>> >>> Ian Stuart. >>> Developer: Open Access Repository Junction and OpenDepot.org >>> Bibliographics and Multimedia Service Delivery team, >>> EDINA, >>> The University of Edinburgh. >>> >>> http://edina.ac.uk/ >>> >>> This email was sent via the University of Edinburgh. >>> >>> The University of Edinburgh is a charitable body, registered in >>> Scotland, with registration number SC005336. >>> >> >> >> * http://en.wikipedia.org/wiki/Worse_is_better > > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
