---------- Forwarded message ----------
From: Scott Wilson <scott.bradley.wil...@gmail.com>
Date: 19 January 2011 22:49
Subject: Re: content negotiating for package formats
To: techadvisorypa...@swordapp.org
I think its time to take a step backwards here.
The "packaging problem" identified by the SWORD project was not that
SWORD or AtomPub have a problem with POSTing packaged content formats.
The problem is that implementations of SWORD in the academic
repositories community use - needlessly, IMHO - diverse incompatible
formats, especially of metadata within a package.
I don't see that adding any number of HTTP headers is going to improve
interoperability while this remains the case. If nothing else, I
would expect implementations to largely ignore any such headers sent
by the client and look inside the package to try and figure out what
it is and if it can support it. The headers just provide more
opportunities for client error.
I would suggest SWORD is completely agnostic on the subject of
packaged content formats, but that the SWORD implementation community
make a concerted effort to identify and support a common core of
packaging and metadata formats so that there is practical
on-the-ground interoperability with a reliable default format for
client implementations to support out-of-the-box.
S
On 19 Jan 2011, at 08:06, Richard Jones wrote:
> 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
