Subject: Re: Atom Content Negotiation

From: Alistair Miles <[email-masked]>
Date: Mon, 16 May 2011 10:22:25 +0100

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-masked]  -  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-masked]
Tel: +44 (0)1865 287669

---

From: Alistair Miles <[email-masked]>
Date: Mon, 16 May 2011 11:33:55 +0100

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

---

From: Alistair Miles <[email-masked]>
Date: Tue, 17 May 2011 10:05:40 +0100

> href="http://example.org/foo?inlinecontenttype={inlinecontenttype}"/>

On reflection, I don't think the link template idea above is a good solution, 
because the client has no way of finding out what inline content types are 
available.

I wonder if a better solution would be to invent three new pieces of machinery:

* a new @inline-type extension attribute for use on atom:link elements

* a new Accept-Inline HTTP header

* a new <accept-inline> element for use within app:collection elements in Atom 
service documents

So, to satisfy your use case, you could publish an Atom feed with links like...

<feed xmlns="http://www.w3.org/2005/Atom">
  <link rel="alternate" type="application/atom+xml;type=feed" inline-type="text/html" href="..."/>
  <link rel="alternate" type="application/atom+xml;type=feed" inline-type="application/json" href="..."/>
  <link rel="alternate" type="application/atom+xml;type=feed" inline-type="application/rdf+xml" href="..."/>
  ...
</feed>

Also, clients and servers could negotiate about the inline content type when 
making GET requests, e.g, ...

GET /foo
Host: example.org
Accept: application/atom+xml
Accept-Inline: application/rdf+xml

200 OK
  
<feed xmlns="http://www.w3.org/2005/Atom">
  <link rel="alternate" type="application/atom+xml;type=feed" inline-type="text/html" href="..."/>
  <link rel="alternate" type="application/atom+xml;type=feed" inline-type="application/json" href="..."/>
  <link rel="alternate" type="application/atom+xml;type=feed" inline-type="application/rdf+xml" href="..."/>
  ...
  <entry>
    <content type="application/rdf+xml">
      <rdf:RDF ...>
      </rdf:RDF>
    </content>
    ...
  <entry>
  ...
</feed>

Also, for editable collections, an Atom server could advertise its intention to 
only accept Atom entries with a particular inline content type within the 
service document, e.g.:

<app:service>
  ...
  <app:workspace>
    <app:collection href="http://example.org/foo">
      <app:accept>application/atom+xml;type=entry</app:accept>
      <x:accept-inline>application/rdf+xml</x:accept-inline>
    </app:collection>
  </app:workspace>
</app:service>

Just a thought.

Cheers,

Alistair

---

From: Mo McRoberts <[email-masked]>
Date: Tue, 17 May 2011 19:50:57 +0100

I've only been half-following this debate, but it strikes me that there's perhaps a certain degree of crossover with the HTTP “Alternates” header:

http://gewis.win.tue.nl/~koen/conneg/draft-ietf-http-alternates-00.html

M.

---

From: Erik Wilde <[email-masked]>
Date: Tue, 17 May 2011 11:56:05 -0700

hello mo.

thanks for the email.

> http://gewis.win.tue.nl/~koen/conneg/draft-ietf-http-alternates-00.html

not really. this addresses the question of resources being available in 
alternate media types. the main problem in the suggestion i was making 
is that everything is always packaged in atom XML, so the media type 
from an HTTP point of view is always atom. think of it as the equivalent 
of how to communicate that you have a web page with flash animations, 
and one with animated GIFs. both are using the HTML media type, but 
something inside of them is different, and afaik, there is no generic 
web/HTTP way how to communicate this (i.e., being able to say: over 
there, there's an equivalent web page, but it has flash in it).

cheers,

dret.

---

From: Mo McRoberts <[email-masked]>
Date: Tue, 17 May 2011 20:47:58 +0100

On 17 May 2011, at 19:56, Erik Wilde wrote:

> not really. this addresses the question of resources being available in alternate media types. the main problem in the suggestion i was making is that everything is always packaged in atom XML, so the media type from an HTTP point of view is always atom. think of it as the equivalent of how to communicate that you have a web page with flash animations, and one with animated GIFs. both are using the HTML media type, but something inside of them is different, and afaik, there is no generic web/HTTP way how to communicate this (i.e., being able to say: over there, there's an equivalent web page, but it has flash in it).

oh right, I see - so it's actually the description of *encapsulated* media types. my apologies!

M.

---

From: Hadrien Gardeur <[email-masked]>
Date: Wed, 18 May 2011 15:25:57 +0200

> * a new <accept-inline> element for use within app:collection elements in

These are three different problems though...
Erik seems to be strictly interested in solving the first one, and in this
case, would a single attribute with a secondary mimetype be enough ?
I don't think that we need a new rel value, or that we should limit this new
attribute to a specific rel either. While you're strictly talking about
alternate versions of the same content, this attribute would also be useful
for other use cases (for example I might publish a music review as an atom
entry, and provide a link@rel="related" with type="application/zip" and
inline-type="audio/mpeg").

Hadrien

---

From: Alistair Miles <[email-masked]>
Date: Thu, 19 May 2011 11:06:02 +0100

Hi Hadrien,

> case, would a single attribute with a secondary mimetype be enough ?

Yes, absolutely. I was just thinking that, if you had all three pieces of 
machinery, then you would have the tools to solve a range or problems all 
related to encapsulated media types, including Erik's. This might be a 
reasonable scope for an internet draft, for example.

> inline-type="audio/mpeg").

Good point.

Cheers,

Alistair