(7) 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 [http://tools.ietf.org/html/rfc4287] was published in December 2005
• AtomPub [Atom Publishing Protocol (AtomPub) (1)] has been published as RFC 5032 [http://tools.ietf.org/html/rfc5032] in October 2007

(8) 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 [http://atompub.org/2005/08/17/atom.rnc])
• Interpretation of content is well-defined (various content types)
• Support for xml:lang and xml:base

(9) 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>

(10) Atom Content

• RSS had no safe way of finding out what an entry's content is
  • this led to different implementations being smart about 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 media 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

(11) 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"/>

(12) 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
• AtomPub [Atom Publishing Protocol (AtomPub) (1)] defines a document format for Category Documents [Category Documents (1)]
• 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

(14) RESTful 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
• AtomPub builds on Atom and adds a RESTful 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

(15) Collections, Members, Entries, Media

• AtomPub's top-level concept is a collection
  • collections are used for managing and organizing members
  • Atom feed documents are the representation of collections
  • collections just exist; there is no way of interacting with them
• 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

(16) Atom/AtomPub Data Model

(17) Protocol Summary

(18) Collection Management

• Managing collections is outside the scope of AtomPub
  • AtomPub allows interactions with existing collections
  • Collection management is inaccessible or using a proprietary protocol
• Metacollections (collections of collections) can extend AtomPub
  • each member in a metacollection corresponds with a collection
  • accessing a metacollection means managing collections
  • AtomPub's existing features can be reused for collection management
• Ongoing discussion in the Atom community
  • currently there is no widely established method

(19) 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 AtomPub is the workspace
  • collections on a server are organized into different workspaces
  • workspaces have no AtomPub 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)
  • AtomPub servers are likely to reject operations not satisfying these constraints

(20) 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>

(21) Category Documents

• Categories are important for creating and reading entries
  • they may contain metadata using any classification scheme
• Service Documents [Service Documents (1)] contain a list of allowed categories
• AtomPub defines a document format for standalone category documents
  • a useful interface between AtomPub systems and other systems using classification schemes
  • REST makes it important to make relevant resources accessible

(22) 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>

(24) Atom/AtomPub as Foundation

• Atom/AtomPub can be used as a foundation
  • apply the methodology of RESTful Web Service Design [RESTful Web Service Design (1)]
  • identify missing representations/links/states
  • add these to the Atom/AtomPub model
• Atom has a well-defined extension model
  • foreign markup must be silently ignored by Atom processors
  • foreign markup is not allowed to change the semantics of Atom markup
  • every Atom extension must be well-behaving with plain Atom processors
• Atom can serve as a good example for extensible markup
  • if you're not using Atom, consider using Atom's extension model [http://tools.ietf.org/html/rfc4287#section-6]

(25) RESTful Web Service Design

• URIs are used for resource identification [Representational State Transfer (REST); Resource Identification (1)]
• HTTP's methods are used as the uniform interface [Representational State Transfer (REST); Uniform Interface (1)]
• Representations [Representational State Transfer (REST); Self-Describing Messages (1)] can use any syntax and structure
• Hypermedia [Representational State Transfer (REST); Hypermedia Driving Application State (1)] is based on links in representations
• Use transaction resources to create stateless interactions [Representational State Transfer (REST); Stateless Interactions (1)]

(26) RESTful Web Service Design Procedure

1. Figure out the data set
2. Split the data set into resources
3. Name the resources with URIs [Representational State Transfer (REST); Resource Identification (1)]
4. Expose a subset of the uniform interface [Representational State Transfer (REST); Uniform Interface (1)]
5. Design the representation(s) [Representational State Transfer (REST); Self-Describing Messages (1)] accepted from the client
6. Design the representation(s) [Representational State Transfer (REST); Self-Describing Messages (1)] served to the client
7. Design hypermedia integration [Representational State Transfer (REST); Hypermedia Driving Application State (1)] with other resources
8. Figure out the normal control flow [Representational State Transfer (REST); Stateless Interactions (1)]
9. Figure out error conditions

(28) Simple Syndication

• RESTful services depend on representations
• Some aspects of representations may be generic
• Reuse existing patterns instead of reinventing the wheel
• Atom/AtomPub at least are useful design patterns
• (So far) there is no "JSON/RDF Atom" (but watch Collection+JSON [http://amundsen.com/media-types/collection/] and LDP [http://www.w3.org/2012/ldp/])