---------- Forwarded message ----------
From: Ian Stuart <[email protected]>
Date: 19 January 2011 01:11
Subject: Re: content negotiating for package formats
To: [email protected]
On 10/01/11 18:49, Richard Jones wrote:
>
> It's looking like a separate header is the way to do this, with the
> following couple of options immediately standing out:
>
> Accept-Features (or X-Accept-Features if it isn't sufficiently official)
> X-Packaging
> X-Accept-Packaging (which I just made up for the purposes of this
> discussion)
>
> Some comments on these:
>
> Accept-Features
> Having looked at the document [1] (thanks Graham (K)) it looks like it
> would give us the leeway that we need to describe requirements while
> ensuring that Graham (T)'s concerns (which I share) about matching up
> package format requirements with mimetypes would be dealt with. On the
> other hand, this document is 12/13 years old and the header has not made
> it into the HTTP content negotiation documentation and is significantly
> different in format to all the other Accept- headers. It could also be a
> substantial effort for servers to implement the full requirements of
> this header.
>
> X-Packaging
> I'm against using this in this way as it is already used to alert the
> server during POST as to the package format that is being supplied. The
> format of the header for content negotiation would have to be totally
> different to this usage: a list of package formats and q values for
> example, rather than a single definitive URI. I see scope for confusion.
>
> X-Accept-Packaging
> Given my concerns about X-Packaging and the comments above about
> Accept-Feature, perhaps there is a middle ground that we can define
> which does something more minimal with just mimetypes, package formats
> and q values in a way similar to having a mimetype that has added
> parameters.
>
> For example:
> Accept: application/zip; q=1.0, application/atom+xml;type=entry;q=0.8
>
> X-Accept-Packaging: application/zip;{package=METSDSpaceSIP};q=1.0,
> application/atom+xml;type=entry;{package=AtomSIP};q=0.8
>
> Or some other suitably neat and unambiguous serialisation which is in
> line with how the other Accept- headers work and also gives us the
> information we want in a totally definitive mimetype<->package format
> way. This could be supplied alongside the usual Accept header so that
> clients which can't generate the X-Accept-Packaging header can fall back
> easily to the usual content negotiation route.
I'm still unclear why there is a need to combine the content type
("application/zip; q=1.0") with the data encoding ("METSDSpaceSIP;
q=1.0")
Can't you say "(1) I only deal in .tgz content, and (2) you can
package whatevers within that content as 'Foo', 'Bar', or even
'Acme::WhiteSpaceEncoded'"
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
