---------- Forwarded message ----------
From: Richard Jones <rich...@oneoverzero.com>
Date: 19 January 2011 21:06
Subject: Re: content negotiating for package formats
To: Ian Stuart <ian.stu...@ed.ac.uk>
Cc: techadvisorypa...@swordapp.org
Hi Ian,
On 18/01/11 12:11, Ian Stuart wrote:
>
> 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'"
I think that the problem is that you can't guarantee that the list of
content types and the list of packaging types are combinable in a
meaningful way; Graham T's email had an example.
So suppose a server can give you content type A with packaging formats
X and Y, or content type B with packaging format Z:
A + (X or Y)
B + Z
and your content negotiation header says:
Accept: A; q=1.0, B; q=0.8
Accept-Packaging: Z; q=1.0, X; q=1.0
Which combination do you return?
On the other hand, this is a general problem and even within the Media
Feature syntax that Graham K describes in his RFC acknowledges this
effectively limits the use of "q" values to top-level feature sets.
So, you would be limited to content negotiating for:
Accept-Media-Feature: A(X), B(Z), A(Y)
for example; i.e. explicitly declaring your preference of the
combination of content-type and packaging format.
I've spent the last 3 or 4 days looking at the Media Feature stuff in
detail, and I have to confess it does feel like a sledgehammer to
crack a nut. At the moment I'm playing with specifying restricted
version of it to see if we can get the effect that we want without the
huge overhead of a full implementation.
As a consequence, I'm still open to Ian's suggested approach here,
provided that we can decide a) what the new HTTP header should be
called, and b) what the rules for resolving content negotiation
ambiguities as shown above should be.
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
