Re: Atom Content Negotiation

[Alistair Miles <[e-mail]>]

Hi Erik,

Apologies, I wrote the message below before reading the rest of the discussion 
thread, and I think I misunderstood your requirement. My suggestion only allows 
you to retrieve a variant (non-Atom) representation of an entire feed, which, as 
you point out, requires a specification of how to completely represent atom 
feeds in html, json, rdf or whatever.

I don't have a solution for how to request or discover variant representations 
of an atom feed, where the main media type is still 
application/atom+xml;type=feed, but where the media type of the entry content 
varies.

Interestingly, I have also run into problems where the media type of the content 
of an Atom entry can vary, and have found myself wanting some 
additional machinery. E.g., I have found myself inventing an <x:accept-inline> 
extension element for atom service documents, to allow servers to say something 
like "I will accept Atom entries, but only where the inline content type is 
text/html".

As Hadrien points out, this seems to be a more general problem, which is 
encountered whenever you have a media type for containers or compound documents 
- you end up wanted some additional machinery which parallels existing HTTP and 
Atom machinery for talking about media types, but within the outer container. I 
think the SWORD folks are struggling with something similar, where they want to 
be able to talk in HTTP and Atom about different "packaging" formats which may 
share the same base media type (e.g., application/zip). They've ended up 
inventing new HTTP headers etc., e.g., "Accept-Packaging".

One thought that does occur, as something you could deploy without having to get 
into debates about media type parameters, perhaps you could invent a new link 
relation like "atom-content" as you suggest, and use it in a link template which 
tells a client how to request a variant representation of a feed with a given 
inline content type. E.g., something like...

<link-template rel="alternate-content" 
href="http://example.org/foo?inlinecontenttype={inlinecontenttype}"/>

...just a thought, this has probably occurred to you already.

Cheers,

Alistair

On Mon, May 16, 2011 at 10:22:25AM +0100, Alistair Miles wrote:
> Hi Erik,
> 
> On Thu, Apr 28, 2011 at 05:31:10PM -0700, Erik Wilde wrote:
> > 
> > hello.
> > 
> > on http://dret.typepad.com/dretblog/2011/04/atom-content-negotiation.html
> > i have posted some thoughts on whether there should eb a way how to
> > differentiate between "feed variants", so that publishers could link
> > the HTML feed to the XML feed. any feedback would be very welcome,
> > both encouraging and critical. commenting on the blog might be
> > better visible, and i will take the freedom to link back from the
> > blog to the mailing archive if there are interesting follow-up
> > mails, unless you don't want me to do so.
> 
> Why not just use <atom:link rel='alternate' href='...'/> at both the feed and 
> entry levels? 
> 
> In our data repository systems (based on AtomPub), both collections and 
> collection members are content negotiable resources. I.e., you can retrieve an 
> Atom, HTML or JSON representation, by specifying different preferences in the 
> Accept request header. In addition to this content negotiation at the collection 
> or member URI, each variant representation also has a URI, and links are 
> provided in entry and feed representations to all variant representations via 
> the 'alternate' link relation.
> 
> E.g., 
> 
> GET /foo
> Host: example.org
> Accept: application/atom+xml
> 
> 200 OK
> Content-Type: application/atom+xml;type=feed
> Content-Location: http://example.org/foo?format=atom
> Vary: Accept 
> 
> <atom:feed xmlns:atom="http://www.w3.org/2005/Atom">
>   <atom:link rel="self" href="http://example.org/foo"/>
>   <atom:link rel="alternate" type="text/html" href="http://example.org/foo?format=html"/>
>   <atom:link rel="alternate" type="application/json" href="http://example.org/foo?format=json"/>
>   ...
>   <atom:entry>
>     <atom:link rel="edit" href="http://example.org/foo/bar"/>
>     <atom:link rel="alternate" type="text/html" href="http://example.org/foo/bar?format=html"/>
>     <atom:link rel="alternate" type="application/json" href="http://example.org/foo/bar?format=json"/>
>     ...
>   </atom:entry>
> </atom:feed>
> 
> FWIW, this is implemented using a generic content negotiation plugin for 
> AtomBeat [1], sorry no documentation as yet.
> 
> Cheers,
> 
> Alistair
> 
> [1] http://code.google.com/p/atombeat/wiki/ReleaseNotes#configurable_conneg_plugin 
> 
> > 
> > thanks and kind regards,
> > 
> > dret.
> > 
> > -- 
> > erik wilde | mailto:[e-mail]  -  tel:[phone] |
> >            | UC Berkeley  -  School of Information (ISchool) |
> >            | http://dret.net/netdret http://twitter.com/dret |
> > 
> 
> -- 
> Alistair Miles
> Head of Epidemiological Informatics
> Centre for Genomics and Global Health <http://cggh.org>
> The Wellcome Trust Centre for Human Genetics
> Roosevelt Drive
> Oxford
> OX3 7BN
> United Kingdom
> Web: http://purl.org/net/aliman
> Email: [e-mail]
> Tel: [phone]

-- 
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health <http://cggh.org>
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Web: http://purl.org/net/aliman
Email: [e-mail]
Tel: [phone]