---------- 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

Reply via email to