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:[email protected] - tel:+1-510-6432253 | > > | 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: [email protected] > Tel: +44 (0)1865 287669 -- 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: [email protected] Tel: +44 (0)1865 287669
