Proposal started by [MikeDavies] (aka Isofarro). The idea for the Simplified Feed Formats was originally conceived by SeairthJacobs and KenMacLeod. This proposal is closer to the original SimpleFeedFormat than the SuperSimpleFeedFormat.


This proposal treats an AtomEntry as the primary document - as a document in its own right. This reduces the AtomFeed to a list of pointers to AtomEntry documents. This proposal extends the scope of AtomFeed beyond being a feed targeted to be read and processed by news aggregators, and introduces simple features amenable to publishing systems and high-volume change-logs and feeds.

A proposed absolute minimim simplified feed format is:

<?xml version="1.0" encoding="utf-8"?>
<feed version="0.3" xmlns="">
 <title>List of entries on this blog</title>
 <link rel="alternate" type="application/x.atom+xml" href=""/>

  <link rel="alternate" type="application/x.atom+xml" href=""/>
  <title>Simplified feed snapshot</title>
 ... more entries ...



The core use case for the simplified feed format meets are the cases where sending list "pointers" to entries is more effective and efficient than sending aggregator-ready Atom entries with content. Subscribing to a simplified feed format in an aggregator would be analogous to subscribing to high-volume linkblog of Atom entries. In an aggregator it can fill in as a "notification" mechanism, but there is a better use case as a summary feed in batch-type transactions between Atom clients and Atom servers.

Four use cases for using a minimal simplified feed:

1.) Rapidly moving change logs / recent changes. [WWW]Wikipedia's Recent Changes which lists the last 50 changes covers a time span of four minutes. The front page of [WWW] shows 1303 new blog entries over the last 1 hour.

The current etiquette of requesting a feed every hour would return feeds of 1000+ items. A human reader is incapable of making use of the majority of information in such a heavy feed over the next hour, so a vast majority of information sent is left unused - this will repeat itself when the feed is re-requested an hour later to get the next 1000 changed entries. A more likely scenario is that a human reader would select a handful of entries at random - probably based on the title of the post.

In this particular use case, a stripped down bare-essentials entry would give the human reader sufficient information to make a decision (out of curiosity or interest) to whether the entry is worth reading. When an entry is deemed acceptable to read, clicking on the title would result in just that entry being sent to the Atom client.

2.) Archiving entries. It is good practice to backup the contents of a blog (and any Atom Service), and doing this from the Atom client seems a natural step. Typically a backup would require every Atom Entry to be retrieved from a server and stored somewhere safe by the client. Rather than sending one massive Atom feed with all the entries created or modified since the last backup, it may be better for the feed to return a simplified list of entries matching that criteria, with the idea that each entry needing to be backed up or changed can be requested individually from the client.

3.) Synchronising remote clients. People use more than one machine or desktop over the course of a day, as a result, the ability to synchronise Atom clients on different machines would be extremely helpful. A simple means of synchronising multiple Atom clients and one Atom server would be by exchaning a list of available Atom resources. This could be done by an Atom client requesting a simplified feed which lists all the Atom entries from the server, and from that the client would chose which entries need to be downloaded, which entries need to be uploaded, and which entries would need to be deleted.

4.) Keyword searching. Sometimes it is necessary for a blog author to find a previously written entry so that it can be linked to. Using a keyword search may return a list of hundreds of entries. Sometimes the apperance of just the blog title is enough for a searcher to correctly identify the blog entry he wishes to link to, so returning the actual content of all the matching blog entries is bandwidth overkill. A more efficient solution would be to return a simplified feed format of title, id and link, perhaps create date. A searcher would scan the list of titles, likely looking titles can then be individually retrieved from the Atom Service.


4.13.6 "atom:modified" Element

Replace the paragraph:


4.13.7 "atom:issued" Element

Replace the paragraph:



Copied and pasted initially from SuperSimpleFeedFormat:


Simplified Feed links: SimpleFeedFormat, SuperSimpleFeedFormat, SsFfLinkList

I initially took out the author and link elements from the feed, but the value of these elements on the feed level outweigh the miniscule bandwidth saving. [MikeDavies]