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="http://purl.org/atom/ns#"> <title>List of entries on this blog</title> <link rel="alternate" type="application/x.atom+xml" href="http://www.example.com/searchResult.atom"/> <author> <name>Isofarro</name> </author> <entry> <link rel="alternate" type="application/x.atom+xml" href="http://www.example.com/2003/helloWorld.atom"/> <id>tag:example.com,2003:3.2397</id> <title>Simplified feed snapshot</title> </entry> ... more entries ... </feed>
7 June 2004 - withdrawn. I'm struggling to justify why we shouldn't need created and modified dates on these feeds. With no changes, the Atom feed spec does offer enough room for "lite" feeds without content and summary. [MikeDavies]
3 June 2004 - 1st draft
I think the key aspect of SimplifiedFeedFormat is/was that it would have some kind of flag that says "fetch the <entry> when it changes to get full content". I think some of the esoterics of the Rationale below are unnecessary, and what's missing from the proposal seems to be the indicator/flag that the entry should be fetched. -- KenMacLeod
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. Wikipedia's Recent Changes which lists the last 50 changes covers a time span of four minutes. The front page of weblogs.com 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:
The "atom:modified" element is a Date construct that indicates the time that the entry was last modified. atom:entry elements MUST contain an atom:modified element, but MUST NOT contain more than one.
The "atom:modified" element is a Date construct that indicates the time that the entry was last modified. atom:entry elements SHOULD contain an atom:modified element, but MUST NOT contain more than one.
4.13.7 "atom:issued" Element
Replace the paragraph:
The "atom:issued" element is a Date construct that indicates the time that the entry was issued. atom:entry elements MUST contain an atom:issued element, but MUST NOT contain more than one.
The "atom:issued" element is a Date construct that indicates the time that the entry was issued. atom:entry elements SHOULD contain an atom:issued element, but MUST NOT contain more than one.
Copied and pasted initially from SuperSimpleFeedFormat:
The SSF assumes additional data and extensions are in the linked entry, not the feed.
This proposal incorporates the suggestion that the "feed" resource be used as the "entry point" into previous feed resources that can be used to access a larger history of the site.
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]