Subject: Atom Content Negotiation (follow-up)

From: Erik Wilde <[email-masked]>
Date: Sat, 30 Apr 2011 12:20:20 -0700

hello.

on 
http://dret.typepad.com/dretblog/2011/04/atom-content-negotiation.html i 
suggested a <link> usage that is not allowed by atom (because extension 
attributes need to be namespaced), but i think the problem is worth a 
solution and i'm planning to write a small draft for it.

the problem is that this link relation needs a parameter (specifying 
what the media type of the linked feed/entry/content is) and maybe some 
title text. following typical XML usage, it might be useful to define an 
extension attribute (for the machine readable information) and allow a 
title (for an optional human readable label). the link relation then 
would be used this way (pointing to a feed with XML content):

<link rel="alternate-content" href="..." 
alternate-content:content-type="application/xml" title="XML version 
based on bla.xsd"/>

i am wondering what people are thinking about this kind of link 
relation. is it looking to unusual (an attribute that would be required 
for this link relation)? if so, what other way of representing it would 
you prefer?

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 |

---

From: James Holderness <[email-masked]>
Date: Sat, 30 Apr 2011 20:02:18 +0000

> solution and i'm planning to write a small draft for it.

I don't get why you rejected the "link content variants" solution. You don't necessarily have to include the HTML version inline - you could just have a very basic text summary.

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

  <title>Example Feed</title>
  <link href="http://example.org/"/>
  <updated>2003-12-13T18:30:02Z</updated>
  <author>
    <name>John Doe</name>
  </author>
  <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
 
  <entry>
    <title>Atom-Powered Robots Run Amok</title>
    <link type="text/html" href="http://example.org/2003/12/13/atom03.html"/>
    <link type="application/xml" href="http://example.org/2003/12/13/atom03.xml"/>
    <link type="application/json" href="http://example.org/2003/12/13/atom03.json"/>
    <link type="application/rdf+xml" href="http://example.org/2003/12/13/atom03.rdf"/>
    <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
    <updated>2003-12-13T18:30:02Z</updated>
    <summary>Some text.</summary>
  </entry>

</feed>

And even the summary isn't strictly necessary. You don't seem to be particularly interested in producing a feed that would be useful to a typical feed reader, so you might as well go with the bare minimum necessary to make the feed valid.

If you think it absolutely necessary to create a new rel type to make your system work, you should probably be asking yourself whether you really want Atom as your data format.

TLDR: I think your proposal sucks.

---

From: Erik Wilde <[email-masked]>
Date: Sat, 30 Apr 2011 22:31:23 -0700

hello james.

> I don't get why you rejected the "link content variants" solution. You
> don't necessarily have to include the HTML version inline - you could
> just have a very basic text summary.

i don't reject it, but it makes it necessary to issue additional GET 
requests for each single entry. if you know that all you ever want are 
the linked alternate variants, then it would be much more effective to 
simply GET those in a feed (if there was one and you could find it).

> And even the summary isn't strictly necessary. You don't seem to be
> particularly interested in producing a feed that would be useful to a
> typical feed reader, so you might as well go with the bare minimum
> necessary to make the feed valid.

i am interested in producing feeds that are useful to feed-consuming 
clients. human-oriented feed clients prefer HTML, whereas other types of 
clients might prefer XML or RDF or something else.

looking forward, i want to use feeds for pushing content, and in 
particular in frameworks supporting fat pings (such as PudSubHubbub), 
the effectiveness of pushing would be greatly diminished if for each 
pushed entry, the client would then need to GET the linked content 
variant. instead, it would be much better if different clients would be 
able to discover feed variants and then get the content pushed to them 
that they want.

these use cases may not be the ones you're interested in, but they do 
exist, and therefore i am wondering how to best address them.

thanks and cheers,

dret.