---------- Forwarded message ---------- From: Ian Stuart <ian.stu...@ed.ac.uk> Date: 11 January 2011 03:04 Subject: Re: content negotiating for package formats To: techadvisorypa...@swordapp.org
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
