This is a perfectly reasonable option, if it fulfills community requirements.
(I just want to on record with this, as I am also putting the case for use of
existing conneg facilities.)
But even if there's no negotiation, if there remains any choice of packaging
format to send then there should be a clear way to unambiguously communicate
what is used. Content-features might help here.
#g
--
Scott Wilson wrote:
> 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
