Enjoying watching the discussion :) getting good now... keep it coming. /dff
> -----Original Message----- > From: Scott Wilson [mailto:scott.bradley.wil...@gmail.com] > Sent: 19 January 2011 09:50 > To: techadvisorypanel@swordapp.org > Subject: Re: content negotiating for package formats > > 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 > > > >
