SuperSimpleFeedFormat
-
Original thread on Atom-syntax mailing list.
-
Second thread on Atom-syntax mailing list.
-
IRC chat -- SamRuby and KenMacLeod
-
IRC chat -- SeairthJacobs and KenMacLeod
Status: proposal
Description: This document proposes the primary recommended profile of the Atom feed format currently described here.
Principle Differences:
-
An <entry> in SSFF feed profile is as minimal as possible.
-
SSFF assumes additional data and extensions are in the linked entry, not in the feed.
-
SSFF assumes the linked AtomEntry has the same access rights as the feed (public or protected). This doesn't necessarily mean the resource contains all the information available to the owner of the resource.
-
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.
Principle Benefits:
-
Atom is intended for use beyond syndication, most notably as a publishing format.
When used for publishing, the AtomEntry becomes the primary document, not the feed. However, it now means that the same entry potentially exists in two places, when it should only ever need to exist in one. This brings up issues such as which entry is the "primary" one and how the entries are kept synchronized. These issues become even greater if the entry is available in more than one feed. By reducing the feed's entry element to a pointer, this allows the entry to be kept in a single location, regardless of the number of feeds. It also gets rid of the question of which entry is the "primary" one.
-
Without this proposal, feeds can potentially get very large.
Retrieving the entire feed just to check for new and updated entries can mean a major waste of bandwidth. By reducing the feed format, this ensures that the feeds always stay small (relatively, anyhow). Then, based on the information in the feed, the appropriate individual entries can be fetched, using no more bandwidth than is necessary. (note: All client and server implementations SHOULD support conditional GETs, regardless of the feed or entry format.)
-
Publishers who previously restricted their feeds to just summary content, due to bandwidth concerns, can now provide their full content at the AtomEntry link and expect clients to only fetch it once, each time it changes. This does not affect providers who do not wish to syndicate full content (they don't need to put it in the public AtomEntry) nor does it affect re-publication rights of super-aggregators (which are currently underspecified).
-
Incorporating the "prev" link to previous feeds can further reduce the size of the very highly accessed feed resource.
The "feed" resource can be tuned to provide just notification service of new items. New subscribers will still be able to get the last N entries and aggregators can continue to track changes to previous entries.
The entry element of a feed would have the format defined below.
SimpleFeedFormat is essentially the same proposal, but with a few additional elements of information to allow a client to create a human readable list of items without actually fetching those items.
ParticleWave is a proposal that suggests that the linked-to entry doesn't need to be an AtomEntry, but could, or should, be an X/HTML, plain text, or other per-item appropriate media-type.
'entry' Element
This element contains one attribute, named etag, which is optional. If present, the etag attribute contains an opaque string which MUST change each time the associated AtomEntry document is updated. This value could be the same as would be seen in the etag HTTP header of the associated AtomEntry document, the value of the entry's modified timestamp, a version-specific URL, a revision counter, etc. Clients SHOULD support this attribute, but are not required to. Similarly, servers SHOULD support this attribute, but are not required to. If both client and server support the attribute, then it MUST be honored before the etag of the AtomEntry document itself.
The element also contains two required elements, named id and link.
'id' Element
The id element contains an opaque string, it's value being the same as the value of the id element in the AtomEntry document. This value MUST not change for the lifetime of the entry. This value MUST be globally unique. This element can be used to:
-
Determine if the value of the 'link' element has changed. Without it, a client could not know that a possibly new entry points to the same AtomEntry document without retrieving the new entry. Note that this isn't the only way to solve this problem. Since the AtomEntry document itself has an id element, it would be possible to re-retrieve the entry via the new link URL, then compare it against existing entries already retrieved.
-
Determine if the same entry is being listed in more than one feed. If an entry is made available in more than one feed (e.g. because it is syndicated like a comic strip or Ann Landers, or because it is categorized in multiple ways), then it would be possible to avoid duplicate downloads, regardless of whether the link URL was the same or not.
'link' Element
The link element contains a URL pointing to the associated AtomEntry document. In order to retrieve information such as title, the update timestamp, and the content, the AtomEntry document must be fetched separately from the feed.
Example
This example includes extra fields as described in SimpleFeedFormat, per IRC discussion, and uses the X/HTML form of <link> per the proposed -08 API changes.
<?xml version="1.0" encoding="iso-8859-1"?> <feed version="0.2" xmlns="http://purl.org/atom/ns#"> <link rel="next" type='application/x.atom+xml' title="Next 20 Entries" href="http://.."/> <link rel="prev" type='application/x.atom+xml' title="Previous 20 Entries" href="http://.."/> <link type='application/x.atom+xml' title="Last 20 Comments" href="http://.."/> <link type="application/x.atom+xml" rel='service.post' title="Create a new post on intertwingly.net" href=".."/> <entry> <id>/blog/1630</id> <link rel="alternate" type="text/html" href="1630.html" /> <link type="application/x.atom+xml" rel="service.edit" href="/blog/1630.atomapi" /> <title>One year ago today...</title> <issued>2003-10-29T20:52:57-05:00</issued> <modified>2003-10-29T20:52:57-05:00</modified> </entry> <entry> <id>/blog/1628</id> <link rel="alternate" type="text/html" href="1628.html" /> <link type="application/x.atom+xml" rel="service.edit" href="/blog/1628.atomapi" /> <title>Is <content> required on a POST?</title> <issued>2003-10-29T05:24:12-05:00</issued> <modified>2003-10-29T05:24:12-05:00</modified> </entry> </feed>
-
[SeairthJacobs] I am still unsure of the value of placing the link to edit the Atom entry in the feed. Supposing you have the same entry in multiple feeds, is there a point in placing the link in every one of the feeds? Instead, I would think it should look like the following:
<?xml version="1.0" encoding="iso-8859-1"?> <feed version="0.2" xmlns="http://purl.org/atom/ns#"> <!-- feed-level elements here --> <entry etag="2003-10-29T05:24:12-05:00"> <id>/blog/1628</id> <link rel="alternate" type="text/html" href="1628.html" /> <link rel="alternate" type="application/x.atom+xml" href="/blog/1628.atom" /> <title>Is <content> required on a POST?</title> </entry> </feed>
This simply points at the AtomEntry document (1628.atom). In order to edit it, the appropriate link would be inside of the document (which could be a self-reference, but not required to be).
Also note the addition of the etag attribute. It contains the value of the modified element, but does not imply the additional semantics of that element. Again, I suggest it be treated as an opaque string.
-
[KenMacLeod] The Atom resource at the edit URI is the Atom document. rel="service.edit" is the indicator that that the URI is the one to edit at. It could be described as "derived" from rel="alternate".
Note also, <id> is a URI. I've changed the examples above so that they look more like relative URIs, so that's clearer.
Note further, the only significant thing that prevents <id> from being the human-readable <link> from being the Atom editable <link> is content negotiation -- content negotiation being pretty much broken. Otherwise, the whole SSFF entry could be:
<?xml version="1.0" encoding="iso-8859-1"?> <feed version="0.2" xmlns="http://purl.org/atom/ns#"> <!-- feed-level elements here --> <entry etag="2003-10-29T05:24:12-05:00"> <link href="/blog/1628" /> <title>Is <content> required on a POST?</title> </entry> </feed>
The link is the URI of the entry, a browser retrieving that URI would get a page in the style and navigation of the publisher's site, and an editor would get the Atom entry. The biggest reason we have extra places for <id> and rel="service.edit" is that some publishers want a seperate URI for the <id>, and many tools have a hard time doing content negotiation right. We could resolve this issue by making one "primary" link and have optional URIs that override the primary link as needed.
[SeanPalmer] This is starting to look like a mutation of XHTML. Murray Altheim and I published a draft to allow <meta> elements anywhere within an XHTML document called Augmented Metadata in XHTML which could be a good foundation for SuperSimpleFeedFormat. It may have to be extended to allow <link>, but here's a quick example nontheless:
<?xml version="1.0" encoding="utf-8"?> <html xmlns="http://www.w3.org/1999/xhtml"> <head profile="http://purl.org/atom/ns#"> <link rel="schema.ATOM" href="http://purl.org/atom/ns#" /> <link rel="next" type="application/x.atom+xml" title="Next 20 Entries" href="http://.." /> <link rel="prev" type="application/x.atom+xml" title="Previous 20 Entries" href="http://.." /> <link type="application/x.atom+xml" title="Last 20 Comments" href="http://.." /> <link type="application/x.atom+xml" rel="service.post" title="Create a new post on intertwingly.net" href=".." /> </head> <body> <h1>intertwingly.net</h1> <div> <h2><a rel="alternate" type="text/html" href="1630.html"> One year ago today...</a></h2> <meta name="ATOM.type" content="entry" /> <meta name="ATOM.id" content="/blog/1630" /> <link type="application/x.atom+xml" rel="service.edit" href="/blog/1630.atomapi" /> <meta name="ATOM.issued" content="2003-10-29T20:52:57-05:00" /> <meta name="ATOM.modified" content="2003-10-29T20:52:57-05:00" /> </div> <div> <h2><a rel="alternate" type="text/html" href="1628.html"> Is <content> required on a POST?</a></h2> <meta name="ATOM.type" content="entry" /> <meta name="ATOM.id" content="/blog/1628" /> <link type="application/x.atom+xml" rel="service.edit" href="/blog/1628.atomapi" /> <meta name="ATOM.issued" content="2003-10-29T05:24:12-05:00" /> <meta name="ATOM.modified" content="2003-10-29T05:24:12-05:00" /> </div> </body> </html>
Benefits? Can be read by browsers fairly natively, deals with lang issues and everything else that XHTML has taken care of over the years.
Contributors: SeairthJacobs, KenMacLeod