---------- Forwarded message ---------- From: David Tarrant <d...@ecs.soton.ac.uk> Date: 11 January 2011 03:20 Subject: Re: content negotiating for package formats To: Ian Stuart <ian.stu...@ed.ac.uk> Cc: techadvisorypa...@swordapp.org
I agree with Ian, why can we just use the existing x-packaging header, cos that's how point (2) works in the current sword? Dave T On 10 Jan 2011, at 14:04, Ian Stuart wrote: > We're looking at two things here, are we not? > > 1) we want the data returned in s specific media type (zip file, xml, json, > atom+xml, etc) > 2) we want the content of that data to be encoded in a particular way > (METSDSpaceSIP, METSOARJ, ORE, RDFa, etc) > > I read your email as wanting to combine the two of them in one http header > field. > > The alternative is to use "pragma" fields.... in which case, you can do what > you like :D > > On 07/01/11 17:36, Richard Jones wrote: >> Hi Folks, >> >> I'd be really interested in people's input on the following problem that >> I've come across in creating the first draft of the spec. It's to do >> with how one can content negotiate with a server for a particular >> package format. >> >> Allowing the Media Resource URI to abstractly refer to the contents of >> the resource on the sword server (as per the business case/technical >> design document) means that in order to specify what you want to get >> back from the server when requesting that resource may require content >> negotiation. Content negotiation uses the HTTP Accept- headers, and the >> main "Accept" header itself allows you to list mimetypes and your >> preferences for receiving them, but package formats aren't represented >> by mimetypes (for the most part). >> >> There are two ways that we might go about content negotiating for a >> format (such as the SWORD example format of METSDSpaceSIP) that I can >> see, and I'd like to solicit feedback: >> >> 1/ Use the Accept-Encoding header in some way. This header allows you to >> do things like: >> >> Accept-Encoding: compress, gzip >> >> which seems to suggest that we could put in the package format like: >> >> Accept-Encoding: METSDSpaceSIP >> >> Does anyone have any experience with this header and could tell us >> whether this seems like a reasonable usage of it? >> >> 2/ Define an extension to the application/zip mimetype which allows us >> to specify the package format as a parameter. Parameters are used in >> mimetypes to further refine their definition, as in: >> >> application/atom+xml;type=entry >> >> This is a valid mimetype, and the Atom spec defines the parameter type >> with possible values "entry" and "feed" so that you can more accurately >> identify the content of the thing you are getting back. Content >> negotiation explicitly allows for the use of parameters (although some >> of the details are a little unclear with regard to wildcards). >> >> So we could, for example, specify a parameter "swordpackage" which can >> take the URI of a package format, and construct mimetypes like >> >> application/zip;swordpackage=uri:METSDSpaceSIP >> >> (see http://tools.ietf.org/html/draft-ietf-atompub-typeparam-00) >> >> The questions here are: is this a legitimate extension/approach, would >> this break anything else on the web in general, and is it naive to >> assume that all packages have the top level mimetype of application/zip? >> >> >> There has also been some discussion about the OASIS CMIS standard, and I >> wonder if anyone is familiar enough with it to tell us how that >> community handles this kind of issue (if at all?). >> >> Cheers, >> >> Richard >> >> >> > > > -- > > 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. > ------------------------------------------------------------------------------ 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
