---------- Forwarded message ---------- From: Richard Jones <rich...@oneoverzero.com> Date: 8 January 2011 06:36 Subject: content negotiating for package formats To: techadvisorypa...@swordapp.org
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 ------------------------------------------------------------------------------ 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
