On 19/01/11 11:28, Richard Jones wrote:
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.
To a certain extent, yes.... however that also assumes that SWORD is
only ever a transport mechanism to transfer from Client-to-Server.
To my mind, SWORD is an agnostic transport mechanism: carrying messages
from one "machine" to another "machine", so messages should work
bilaterally.... if the desktop application requests a transfer from the
Learning Object Repository, which way is the "Deposit"?
Hence my suggestion that the whole content negotiation thing should be
manageable from both ends.
--
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.
