People in this thread keep asking for a use case where one would want to have a separate mediatype for both feeds and entry documents, so here is my attempt at providing one.
I view a web page (blog post) that defines the proper link tags to both the Atom Entry for the current post, and the Atom Feed for all the posts on that blog. These links have the proper type and rel information attached to each respective links. No problem there, the browser can decide what to do with those links based off rel information alone. Now, in the template of this page, the author also includes standard html anchors to these two resources for the benefit of users using a browser that doesn't understand Atom Entries let alone Atom Feeds. He's linked the feed to a png image of the standard feed icon, and a similar image for the Entry. These anchors have @href attributes, but no @type or @rel information. I have two programs on my system; A feed reader, which I use to subscribe to Atom Feeds, but has a very limited support for Entry documents; and an APP Editor, which allows me to create and edit Atom Entries, but has limited support for Feeds. If I click on one of these two links on the page, I want that resource to be handled by it's respective program. If these two documents were each to be served with a different mediatype, then it is trivial to tell my OS/Browser to send the Feeds to my feed reader, but send my Entries to my editor. As it stands right now, there would be no way to do this aside from having a third program taking in both, sniffing the content and sending the document to the appropriate program. This is a horrible solution. The @rel attribute is still useful. The @rel exists to tell the browser what to do with the document, the @type exists to say what that document actually IS. I dislike the idea of using ;type=[feed|entry] mostly because I'm afraid that this information will far too likely be either diregarded or dropped. Also, once Entries become their own type, the next logical step would be to have something like: application/atom.entry+xml;type=xhtml application/atom.entry+xml;type=html application/atom.entry+xml;type=text application/atom.entry+xml;type=markdown etc... Of course, let's reach a consensus on this issue before that particular can of worms gets opened up. Daniel E. Renfer http://kronkltd.net/ On 12/7/06, Jan Algermissen <[EMAIL PROTECTED]> wrote:
On Dec 7, 2006, at 8:41 AM, Sylvain Hellegouarch wrote: > Considering you seem to only discuss their value from a feed reader > point of view Hmm, strange. Feed readers are actually the last thing I am thinking about wrt Atom (no intention to show disrespect for the blogosphere of course). Jan
