---------- Forwarded message ---------- From: Scott Wilson <scott.bradley.wil...@gmail.com> Date: 11 January 2011 03:55 Subject: Re: content negotiating for package formats To: techadvisorypa...@swordapp.org
To answer the CMIS question - AFAIK CMIS doesn't explicitly support external packaging formats (in its scope it declares that compound and virtual objects are "extended features"); instead it directly uses Atom's collection handling. So a CMIS client would create the Folder object and then POST each enclosed item to it, rather than POST a zip file and rely on the repository to unpackage and store it as some sort of composite object. There is a line in the CMIS charter setting it as a secondary priority, so it may become part of CMIS in the future. Packaging is also used for supporting alternative renditions of a resource - and CMIS supports this explicitly - see "renditions" in the OASIS CMIS spec: http://docs.oasis-open.org/cmis/CMIS/v1.0/os/cmis-spec-v1.0.html#_Toc243905395 ... however support is currently limited to retrieving renditions, and the spec doesn't specify how to create a document with multiple renditions. This could be a good topic on which to link up with the OASIS CMIS TC. S On 10 Jan 2011, at 14:20, David Tarrant wrote: > 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