Abstract

While RSS-based syndication has become widely used (in particular for user-generated content), the technical and political problems of the format triggered a new development. The Atom format is an improved syndication format, and accompanied by the Atom Publishing Protocol (APP), a REST-based way of interacting with an Atom source. APP includes support for creating, reading, updating, and deleting Atom entries, thus supporting a broad range of resource-centered interactions.

Technical Problems

• What to put into an item's description
  • the fundamental question is whether description is text or HTML
  • if there is no well-defined way, then interpretation is client-specific

    <description>This is a <em>very important</em> blog post …

    <description>This is a &lt;em>very important&lt;/em> blog post …

    <description>This is a blog post about <em> in RSS feeds …

    <description>This is a blog post about &lt;em> in RSS feeds …

    <description>This is a blog post about &amp;lt;em> in RSS feeds …

• Underspecified and not very robust in various other areas
  • broken RSS is accepted by most readers (but fixing it can change the interpretation)
  • the interpretation of relative URIs is not mentioned in the specifications
  • some minimal semantics (classification) for items would be very useful

Political Problems

• Multiple and incompatible RSS Versions are still in widespread use
  • RSS 1.0 and RSS 2.0 are incompatible by design (RDF vs. non-RDF)
  • none of the RSS versions is maintained by a universally accepted standards body
• None of the specifications is being updated or fixed
  • some of the lessons learned by RSS deployment are not used in a new version
  • it is unlikely that a new version will be produced which merges the RSS landscape
• Invent something new instead of trying to fix RSS
  • Atom started in 2003 (called Echo at first)
  • W3C or IETF would have been promising candidates for a new RSS
  • W3C is more formal, IETF is more developer-centered
  • IETF was chosen over W3C because the of Atom community's preferences

Atom History

• RSS's shortcomings were very apparent and could not be fixed
• In mid-2003, discussions started about an improved format
• It also became apparent that the format should have a protocol
• Atom 0.3 was released in December 2003 but had no formal home
• IETF was chosen as the new home with a working group in June 2004
• RFC 4287 was published in December 2005
• The Atom Publishing Protocol (APP) is under development (here's their RSS …)

Atom vs. RSS

• Standardized by the IETF (well-defined process)
• Classification of entries (user-defined categories)
• More XML-like markup design (more nesting)
• Namespaces are used and supported as standard mechanism
• Atom feeds must be well-formed XML (there even is a schema)
• Interpretation of content is well-defined (various content types)
• Support for xml:lang and xml:base

Atom Example

<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-us">
 <title>ongoing</title>
 <id>http://www.tbray.org/ongoing/</id>
 <link rel='self' href="http://www.tbray.org/ongoing/ongoing.atom"/>
 <updated>2007-04-11T12:55:09-07:00</updated>
 <author>
  <name>Tim Bray</name>
 </author>
 <subtitle>ongoing fragmented essay by Tim Bray</subtitle>
 <entry xml:base="When/200x/2007/04/02/">
  <title>Atom Publishing Protocol  Interop!</title>
  <id>http://www.tbray.org/ongoing/When/200x/2007/04/02/APP-Interop</id>
  <published>2007-04-02T13:00:00-07:00</published>
  <updated>2007-04-10T14:24:00-07:00</updated>
  <category scheme="http://www.tbray.org/ongoing/What/" term="Technology/Atom"/>
  <category scheme="http://www.tbray.org/ongoing/What/" term="Technology"/>
  <category scheme="http://www.tbray.org/ongoing/What/" term="Atom"/>
  <content type="xhtml">
   <div xmlns="http://www.w3.org/1999/xhtml">
    <p>Mark your calendar: <a href="http://www.intertwingly.net/wiki/pie/April2007Interop">April 16-17 at Google</a>. <em>Everybody</em> is invited, provided they bring along an APP implementation, client or server. This was just announced a couple of days ago, and as I write this there are already <s>six</s> twelve client and <s>seven</s> fourteen server implementations signed up to be there and try to <a href="http://www.intertwingly.net/wiki/pie/InteropGrid">fill in the grid</a>.  Let’s drop some names, in alphabetical order:  AOL,  Flock, Google,  IBM,  Lotus,  Microsoft, Oracle, O’Reilly,  Six Apart, Sun, WordPress. Um, have I mentioned that the APP is going to be huge?</p>
   </div>
  </content>
 </entry>
</feed>

Atom Content

• RSS had no safe way of finding out what an entry's content is
  • this led to different implementations using smart ways of what the RSS author really wanted
  • one of Atom's main goals was to improve this in a well-defined way
  • Atom allows escaped markup (the only way to include non-XML HTML in an XML format)
• Each content element should have a type (the default is text)
• Atom's content interpretation algorithm (use first applicable rule):
  1. if type is text, no child elements are allowed (plain text content)
  2. if type is html then RSS's method of escaped markup is used
  3. if type is xhtml then there must be an div containing XHTML markup
  4. if type is an XML MIME type then the content should be treated as this type
  5. if type starts with text/ then no child elements are allowed
  6. for all other values, the content must be an base64-encoded entity of the specified MIME type

Atom Content Examples

<content type="xhtml">
  <div xmlns="http://www.w3.org/1999/xhtml">
    One <strong>bold</strong> foot forward
  </div>
</content>

<content>The "atom:content" element either contains or links to the content of the entry. The content of atom:content is Language-Sensitive.</content>

<content type="html">The &lt;code>atom:content&lt;/code> element either contains or links to the content of the entry. The content of &lt;code>atom:content&lt;/code> is &lt;a href="http://www.ietf.org/rfc/rfc3066.txt">Language-Sensitive&lt;/a>.</content>

<content type="image/png">
iVBORw0KGgoA … TAAAAAElFTkSuQmCC
</content>

<content src="image.png" type="image/png"/>

Atom Categories

• Atom allows to assign categories to entries
  • each category element must have a term attribute for the category
  • an optional scheme identifies the categorization scheme (ontology, taxonomy, …)
  • an optional label attribute provides a human-readable label for the category
• Atom Publishing Protocol (APP) defines a document format for Category Documents
• Three different cases of categorization can be distinguished
  1. use a well-known scheme (such as Dublin Core)
  2. use a private but well-designed scheme (which has a URI and can be reused reliably)
  3. use tags without schemes, which then are little more than content labels
• Widely-known tags are not easy to handle
  • they are more than just privately assigned tags
  • there is no formal scheme for them, just an emerging consensus

Switching from RSS to Atom

• Generate both feeds but serve RSS with a HTTP redirect (301)
  • old subscribers with broken clients can still use the RSS feed
  • old subscribers with correct clients will use the Atom feed
• Atom exposes more information than RSS (category for tags)
  • the mapping of publishing info to the feed has to be changed/extended
  • for standard metadata use Atom's built-in metadata elements
  • for application-specific metadata consider reusing an existing metadata schema
• Atom can be used to publish snippets as well as full content
  • content allows any type of content to be used and may contain a complete entry
  • summary allows only text and should provide a condensed version of an entry
  • some Atom sources publish two feeds for summaries and content
• Generate good Atom and downgrade it to RSS 1.0 & 2.0

Syndication Format Protocols

• LiveJournal (very simple text-based protocol)
  • not very good at handling structures (re-inventing for encoding structure)
• Blogger (now at Google after Google bought Pyra)
  • no support for titles or any other sort of entry metadata
  • protocol from the early days of blogging before tagging became popular
• MetaWeblog (an attempt to improve Blogger)
  • extends Blogger using a very bad design (RSS XML as XML-RPC structure encoded as XML)
• Atom Publishing Protocol (APP) is an attempt to provide a clean alternative
  • use the same document structures for feeds and the protocol interacting with them
  • use a REST approach to provide a simple and Web-compatible protocol
  • add Service Documents and Category Documents for additional tasks

RESTified Syndication

• Atom is a format for retrieving a set of entries as a feed document
  • feeds often are time-based and are refreshed periodically or whenever needed
  • feeds can use any other strategy for deciding what to publish
• Read-only access to feeds should be complemented by full access
  • full access needs the CUD out of the CRUD set of operations
  • many Web-centric technologies try to build on the Web's REST model of interaction
• APP builds on Atom and adds a REST-based protocol on top of it
  • POST for creating new entries (sending the request to the collection)
  • PUT for updating existing entries (overwriting the existing entry)
  • DELETE for deleting entries from a collection

Collections, Members, Entries, Media

• APP's top-level concept is a collection
  • collections are used for managing and organizing members
  • Atom feed documents are the representation of collections
• Members of a collection can be entry and media resources
  • entry resources represent metadata and are represented as Atom entries
  • media resources can have any media type and are the data described by entries
  • a media link entry is an entry associated with a member

Protocol Summary

Service Documents

Service Documents represent server-defined groups of Collections, and are used to initialize the process of creating and editing resources.

• The real top-level construct of APP is the workspace
  • collections on a server are organized into different workspaces
  • workspaces have no APP semantics and no operations can be performed on them
• Service documents list constraints on the members of collections
  • accept specifies a comma-separated list of media ranges (with entry as special value)
  • categories defines the list of categories that can be applied to members (can be fixed)
  • APP servers are likely to reject operations not satisfying these constraints

Service Document Example

<service xmlns="http://purl.org/atom/app#" xmlns:atom="http://www.w3.org/2005/Atom">
 <workspace>
  <atom:title>Main Site</atom:title>
  <collection href="http://example.org/reilly/main">
   <atom:title>My Blog Entries</atom:title>
   <categories href="http://example.com/cats/forMain.cats"/>
  </collection>
  <collection href="http://example.org/reilly/pic">
   <atom:title>Pictures</atom:title>
   <accept>image/*</accept>
  </collection>
 </workspace>
 <workspace>
  <atom:title>Side Bar Blog</atom:title>
  <collection href="http://example.org/reilly/list">
   <atom:title>Remaindered Links</atom:title>
   <accept>entry</accept>
   <categories fixed="yes">
    <atom:category scheme="http://example.org/extra-cats/" term="joke"/>
    <atom:category scheme="http://example.org/extra-cats/" term="serious"/>
   </categories>
  </collection>
 </workspace>
</service>

Category Documents

• Categories are important for creating and reading entries
  • they may contain metadata using any classification scheme
• Service Documents contain a list of allowed categories
• APP defines a document format for standalone category documents
  • a useful interface between APP systems and other systems using classification schemes

Category Document Example

<app:categories xmlns:app="http://purl.org/atom/app#" xmlns="http://www.w3.org/2005/Atom" fixed="yes" scheme="http://example.com/cats/big3">
 <category term="animal"/>
 <category term="vegetable"/>
 <category term="mineral"/>
</app:categories>

Linkbases as Feeds

• The current linkbase protocol has a very simple design
  • there is no notion of linkbase management and access control
  • the concept of link identity did not really fit well into the overall concept
• Linkbases can be regarded as APP collections
  • links in the linkbase then are entries in a collection
  • linkbase queries have to be designed as GET queries of a collection
  • links can be created, updated, and deleted using APP's HTTP methods
• Using a two-level approach, linkbase management can be covered as well
  • linkbases on the linkbase server are entries in the server's set of linkbases
  • the set of linkbases can be queried using GET (e.g., searching for specific linkbases)
  • linkbases can be created and deleted using APP's HTTP methods

Item Categories

• The current design has no machine-readable semantics
  • the label/from/to are used for defining arcs
  • semantics would have to be encoded in role and arcrole attributes
• In addition to resource and arc roles, there also can be a link role
  • allows for a classification of links according to some general link classification scheme
• XLink semantics could be reflected in Atom categories
  • the link role could be mapped to the Atom entry's category
  • the available links of linkbases could then be exposed as Category Documents
  • internal semantics (of resources and/or roles) are probably harder to map to Atom

AJAXLink goes APP

• Atom and APP are two interesting technologies for syndication
• Atom is a better syndication format than RSS
• APP is a good foundation for REST-based access to server resources
• AJAXLink in an APP version is easier to understand for developers
• APP is still under development, but nearing completion