The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: June 30, 2010
Atom Publishing Format and Protocol

Final Deliverables:

Update 2005-12-09: In August 2005, the IESG announced the approval of "The Atom Syndication Format" as an IETF Proposed Standard. On December 05, 2005 the IETF issued RFC 4287: The Atom Syndication Format as an official RFC. Mark Nottingham: "Atom has finally realised its most important advantage over the various flavours of RSS: it's a Standards-Track RFC. What does this mean? It doesn't mean that it's (necessarily) technically better, is easier to use, or will be more broadly adopted. Hopefully, it will have these things due to the quality of the WG participants and exposure to the resources of the IETF. What it does mean is that there isn't any contention at all about who owns it and the specification is stable, with a well-understood change process. This doesn't sound like much, but it can be sorely missed when you don't have it, whether you're dealing with a single person or with a huge company..."

Overview

On June 16, 2004 the Internet Engineering Steering Group (IESG) announced the formation of an Atom Publishing Format and Protocol Working Group (atompub) in the IETF Applications Area. According to the initial Working Group Charter, Atom "defines a feed format for representing and a protocol for editing Web resources such as Weblogs, online journals, Wikis, and similar content. The feed format enables syndication; that is, provision of a channel of information by representing multiple resources in a single document. The editing protocol enables agents to interact with resources by nominating a way of using existing Web standards in a pattern."

On October 22, 2007 the IESG announced the completion of the Atom Publishing Format and Protocol WG: The AtomPub WG was chartered to work on two items: the syndication format in RFC 4287, and the publishing protocol in RFC 5023. Implementations of these specs have been shown to work together and interoperate well to support publishing and syndication of text content and media resources. Since both documents are now Proposed Standards, the WG has completed its charter and therefore closes as a WG. A mailing list will remain open for further discussion. Congratulations and thanks to the chairs Tim Bray and Paul Hoffman, to the editors of the two WG RFCs (Mark Nottingham, Robert Sayre, Bill de HÓra and Joe Gregorio), and to the many contributors and implementors. The IESG contact persons are Lisa Dusseault and Chris Newman.

IETF atompub Working Group Charter

Extracted from the initial IETF Working Group announcement:

IETF atompub Working Group Chair(s)

Paul Hoffman <paul.hoffman@vpnc.org>
Tim Bray <tbray@textuality.com>

Applications Area Director(s)

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor

Scott Hollenbeck <sah@428cobrajet.net>

Secretary(ies)

Sam Ruby <rubys@intertwingly.net>

Mailing Lists

General Discussion: atom-syntax@imc.org
To Subscribe: atom-syntax-request@imc.org
In Body: subscribe
Archive: http://www.imc.org/atom-syntax/mail-archive/

Description of Working Group

Atom defines a feed format for representing and a protocol for editing Web resources such as Weblogs, online journals, Wikis, and similar content. The feed format enables syndication; that is, provision of a channel of information by representing multiple resources in a single document. The editing protocol enables agents to interact with resources by nominating a way of using existing Web standards in a pattern.

Atom consists of:

  • A conceptual model of a resource
  • A concrete syntax for this model
  • A syndication and archiving format (the Atom feed format) using this syntax
  • An editing protocol using this syntax

The format must be able to represent:

  • a resource that is a Weblog entry or article (e.g., it has an author, date, identifier, and content)
  • a feed or channel of entries, with or without enclosed content
  • a complete archive of all entries in a feed
  • existing well-formed XML (especially XHTML) content
  • additional information in an user-extensible manner

The editing protocol must enable:

  • creating, editing, and deleting feed entries
  • multiple authors for a feed
  • multiple subjects or categories in a feed
  • user authentication
  • adding, editing, and deleting users
  • setting and getting user preferences
  • creating, getting and setting related resources such as comments, templates, etc.

The working group will use experience gained with RSS (variably used as a name by itself and as an acronym for "RDF Site Summary", "Rich Site Summary", or "Really Simple Syndication") as the basis for a standards-track document specifying the model, syntax, and feed format. The feed format and HTTP will be used as the basis of work on a standards-track document specifying the editing protocol. The goal for the working group is to produce a single feed format and a single editing protocol; the working group will only consider additional formats or additional protocols if those charter changes are approved by the IESG.

The working group will also take steps to ensure interoperability, by:

  • unambiguously identifying required elements in formats
  • clearly nominating conformance levels for different types of software
  • providing clear extensibility mechanisms and constraints upon them

The Atom protocol will be designed to provide security services for updating and accessing dynamic online resources. The working group will consider current known issues with requirements for remote access, along with the fact that many such resources are constrained by providers who provide the resource owners with little configuration control.

The working group's primary focus will be on delivering an interoperable format and corresponding protocol; it is expected that all but the most basic, generic metadata and functions will be accommodated through extensions, rather than in the core documents.

Extension development is not included in this charter. The working group will consider the need to either close or to modify the charter and document extensions once the core document set has been approved by the IESG.

Atom Before the IETF Working Group

As of October 2003, when the Atom project was growing in the wild, an had no official home in a standards organization:

Overview

The Atom Project, to the extent that anyone can declare authoritatively what it is, or is quintessentially meant to support, is "an initiative to develop a common syntax for syndication, archiving, and publishing." Sam Ruby (Emerging Technologies Group, IBM) is most often credited for originating the core ideas, and design work spread across several wikis and weblog Internet sites is now being shared by some of the brightest developer minds focused upon the future of Web content creation and distribution.

The developers agree that Atom "will be vendor neutral, implemented by everybody, freely extensible by anybody, and cleanly and thoroughly specified." Atom is sometimes characterized as the successor to RSS (Really Simple Syndication or RDF Site Summary), which is variably used for news headline syndication, website metadata description, and content syndication. Like RSS, Atom is being created through an informal consensus process by volunteers in the Web developer community at large.

Sam Ruby appears to recognize that the function of Atom will be revealed in unpredictable ways, escaping any telos imagined by the current designers. The key insights are these: design Atom such that content is not treated as a second class citizen (allow its conceptual model and syntax to blur the subjective distinction between metadata and data); insist upon a uniform mechanism for expressing the core concepts independent of the usage (e.g., allow multiple implementation designs conforming to abstract API requirements, and anticipate multiple schema formalisms for validation); keep the format open and simple (e.g., not requiring special serialization of the XML, implementable using simple POST and GET operations under HTTP).

The Atom design is envisioned as extensible for different application areas (license terms, access control, content categorization, versioning, related resources, etc.) The core features are those common to most creations of intellectual works: source/author, editing date(s), resource identifier/location, and content. Given these minimal but central goals, we can understand the simplicity and generality of the abstract for the draft Atom API specification: the API document "presents a technique for using XML and HTTP to edit content." In this context, "edit" means "read, write, modify, delete" (approximately: GET, POST, PUT, DELETE).

The goal of extreme generality remains in tension with the competing objective of ensuring that the new syndication format, while extensible, has predictable consistency at the semantic level. This probably means that the formalism in final draft will specify some required elements. In particular, if an agreed design goal is to capture time sensitive information, then an element for time information would be required. In the draft syntax description [as of 2003-10-22], the top-level <feed> element has required subelements title, link, modified (date in UTC), and author. An <entry> element would have required subelements title, link (URI permanent link), id, issued (W3DTF +/- timezone), and modified.

RoadMap snapshot for Atom (Echo/Pie) as of 2003-10-17: The project roadmap involves: "(1) Decide on the conceptual model of a log entry. Primer, ConceptualModel; (2) Decide on a syntax for this model. Syntax, SyntaxConsiderations; (3) Build a syndication format using this syntax; (4) Build an archiving format using this syntax; (5) Build a weblog editing protocol using this syntax (the Atom API)." According to this RoadMap document, sixty-some companies have pledged support for Atom (aka Echo/Pie/etc) along with 170+ individual developers.

The Internet domain intertwingly.net is host for Sam Ruby's weblog and for the Atom Project wiki, both serving as publication organs for Atom design and development. The www.intertwingly.net "It's Just Data" blog for Atom and related topics is built in XHTML 1.1 code. This is important to one of Sam Ruby's goals for the new syndication format: a desire to enable such things as XPath queries over the content. A blog entry for September 26, 2003 "Fun with XPath" documents some of the details.

Note: Descriptive text above is based in part upon a summary provided by Sam Ruby. Sam presented an overview of Atom at the News Standards Summit on December 8, 2003 (XML 2003 venue).

Atom Entry and Content Model

The content, structure, and (lexical) syntax for Atom <entry> and <content> elements are still [2003-10] under discussion. Mark Pilgrim presents draft examples and some of the key concepts in his article "The Atom API," published by XML.com. Excerpts:

[An Atom entry has] "lots of information: a title, an excerpt or summary, and an author who has a name, email address, and URL of his own. The entry has a 'created' date and a 'modified' date (usually server-generated), and an 'issued' date (which is a date that the author would like to give to this entry, separate from when he actually posted it). The entry is viewable at a specific link, has an internal ID (a URN), and finally has some XHTML content.

The Atom content model is probably worth a whole article by itself, but for the moment let me just handwave and say that it can handle more than just XHTML. Any MIME type can be expressed (specify it in the @type attribute), and non-XML content (such as HTML or plain text) is simply escaped or put in a CDATA block, with a mode="escaped" attribute on the content element. It can even handle binary content (such as an image) by specifying @mode="base64" and including a base64-encoded representation of the data...

The Atom API has several other methods beyond add, edit, delete, retrieve, search. It can be used for posting comments on entries, managing users and user preferences, managing categories, managing site templates; eventually it will be usable for everything you can do manually with your weblog through your server's browser-based interface... [As for] Atom authentication: it does not involve sending plain text passwords in the clear..."

Principal URLs

IETF Internet Drafts

See also the list of individual IDs.

The Atom Syndication Format. IETF Network Working Group, Request for Comments #4287. Category: Standards Track. December, 2005. 43 pages. Atom Syndication Format namespace: http://www.w3.org/2005/Atom. See the announcement. HTML format. See also the XML format version, the Windows Help format, Adobe PDF, and RFC dependencies. [source]

The Atom Publishing Protocol. IETF Network Working Group, Request for Comments #5023. Category: Standards Track. October 2007. 53 pages. Atom Publishing Protocol namespace: http://www.w3.org/2007/app. HTML format from Julian Reschke, or HTML format from IETF. Also, from Julian Reschke: XML format, text in Windows Help format, Adobe PDF, and RFC dependencies. [source]

"The Atom Syndication Format." Approved by the IESG as an IETF Proposed Standard. Awaiting an RFC number. Edited by Mark Nottingham [WWW] and Robert Sayre [WWW]. Preliminary draft contributions from Tim Bray, Mark Pilgrim, and Sam Ruby; Norman Walsh provided the Relax NG schema. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-11'. August 15, 2005, expires February 16, 2006. 56 pages. See the IESG announcement: "Protocol Quality: Scott Hollenbeck and the XML Directorate have reviewed the specification for the IESG. Test implementations have confirmed basic protocol soundness." See HTML and the RELAX NG RNC grammar.

  • [December 18, 2007] "FIQL: The Feed Item Query Language." By Mark Nottingham [Blog]. January 12, 2007. Expires June 14, 2008. 16 pages. Reference: 'draft-nottingham-atompub-fiql-00'. An initial public draft of "FIQL: The Feed Item Query Language" has been released. The Feed Item Query Language (FIQL, pronounced "fickle") is a simple but flexible, URI-friendly syntax for expressing filters across the entries in a syndicated feed. For example, a query "title==foo*;(updated=lt=-P1D,title==*bar)" would return all entries in a feed that meet the following criteria; (1) have a title beginning with "foo", AND (2) have been updated in the last day OR have a title ending with "bar". The specification defines an extensible syntax for FIQL queries, explains their use in HTTP, and defines feed extensions for discovering and describing query interfaces. On the Atom syntax list, the author responded to a question "Why not XPath or XQuery or SPARQL (with an Atom/RDF mapping), or CSS selectors or some subset of one of those?" Mark says: "In a nutshell, there are two reasons; [i] Those query languages are optimised for data models that aren't feeds; respectively, XML Infosets, Infosets again, RDF graphs and CSS cascades. While it's possible to contort them to fit feeds, they don't really lend themselves to it. XQuery and SPARQL also present a fairly high barrier to adoption (if you're not a big XML vendor or a SW-head, respectively ;) Contorting them so that they're easy to fit into a URL isn't too attractive, either. [ii] When you expose a query interface, you're allowing people to consume compute power on your servers. An arbitrary query language allows arbitrary queries, which is unacceptable when you're working across administrative domains. FIQL gives you tools to constrain how queries are shaped. I've been asked this many times, and should probably add it as a FAQ in an appendix. Certainly there are use cases for using XQuery, etc. against feeds, but it's also become apparent that there's a place for something simple, reasonably flexible, and Web-friendly."

  • [July 11, 2007] The Atom Publishing Protocol. Edited by Joe Gregorio (IBM) and Bill de hOra. July 09, 2007, expires January 10, 2008. IETF Network Working Group, Internet Draft 'draft-ietf-atompub-protocol-17.txt'. Status: IETF Proposed Standard. HTML format; XML. I-D Tracker, DataTracker Detail Info. diff 17-vs-16 [alt]. From the announcement: "The IESG has approved the The Atom Publishing Protocol ('draft-ietf-atompub-protocol-17.txt') as a Proposed Standard. This document is the product of the IETF Atom Publishing Format and Protocol Working Group. The IESG contact persons are Lisa Dusseault and Chris Newman. Technical Summary: The Atom Publishing Protocol HTTP-based protocol for publishing and editing web resources, and is particularly useful for (but not limited to) blogs. It supports ideas such as collections of multimedia items and categorization of items. It uses the Atom Format (RFC 4287) for its messages. Working Group Summary: The document went through many revisions and was discussed actively. Protocol Quality: There are already many implementations of the spec from a wide variety of vendors, and many of those have been shown to interoperate. Lisa Dusseault reviewed this for the IESG. Mimimal changes from -v16: (1) Section 12: 'an optional "type" parameter' -->> 'a "type" parameter'; (2) Section 14 deleted [duplicate] text: "At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC 2617] in conjunction with a TLS 1.0 [RFC 2246] or a subsequent standards-track version of TLS, supporting the conventions for using HTTP over TLS described in [RFC2818]." See v -16 and the diff.

  • [July 05, 2007] The Atom Publishing Protocol. Edited by Joe Gregorio (IBM) and Bill de hOra. June 27, 2007, expires December 29, 2007. IETF Network Working Group, Internet Draft 'draft-ietf-atompub-protocol-16.txt'. 67 pages. Atompub Status: IESG Processing, IESG Evaluation — AD Followup (New version available, Sub state has been changed to AD Follow up from New ID Needed). Intended Status: Standards Track. Announced ("I-D ACTION:draft-ietf-atompub-protocol-16.txt"); source .TXT; I-D Tracker. With -16 vs. -15 diff version format. "The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format." Changes: (1) Note change to NS URI http://www.w3.org/2007/app in 6.1 and passim, also reflected in the RELAX NG Compact Syntax Grammar for the Atom Protocol: "A Category Document (Section 7) contains lists of categories specified using the 'atom:category' element from the Atom Syndication Format... A Service Document (Section 8) groups available Collections into Workspaces. The namespace name for either kind of document is: http://www.w3.org/2007/app. The namespace document at new NS URI reports: The namespace name http://www.w3.org/2007/app is intended for use as per The Atom Publishing Protocol, work in progress by the IETF atompub Working Group, issued 8-Jun-2007 by Dan Connolly, W3C/IETF liaison on behalf of the W3C Director to Tim Bray and Paul Hoffman, atompub WG chairs. (2) added inplementation note in Section 9.7.1 (Slug: Header syntax); (3) added text in Section 15 (Security Considerations): "The threats listed in this section apply to many protocols that run under HTTP. The Atompub Working Group decided that the protection afforded by running authenticated HTTP under TLS as described in Section 14 was sufficient to mitigate many of the problems presented by the attacks listed in this section." (4) added clarification in Section 15.5 (Digital Signatures and Encryption): "Neither servers nor clients are under any obligation to support encryption and digital signature of entries or feeds... A server is allowed to strip client-applied signatures..."

  • [June 05, 2007] The Atom Publishing Protocol. Edited by Joe Gregorio (IBM) and Bill de hOra (Propylon Ltd). May 22, 2007, expires November 23, 2007. IETF Network Working Group, Internet Draft 'draft-ietf-atompub-protocol-15.txt'. 68 pages. Status: IESG Evaluation. Intended Status: Standards Track. Announced ("I-D ACTION:draft-ietf-atompub-protocol-15.txt"); source .TXT; I-D Tracker. Also HTML, XML, with -15 vs. -14 diff version format. "The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations as documented in the Atom Syndication Format RFC. The protocol supports the creation of Web Resources and provides facilities for: (1) Collections: Sets of Resources, which can be retrieved in whole or in part; (2) Services: Discovery and description of Collections; (3) Editing: Creating, editing, and deleting Resources. The Atom Publishing Protocol is different from many contemporary protocols in that the server is given wide latitude in processing requests from clients..."

  • [March 04, 2007] The Atom Publishing Protocol. Edited by Joe Gregorio (IBM) and Bill de hOra (Propylon Ltd). March 04, 2007, expires September 05, 2007. IETF Network Working Group. Internet Draft 'draft-ietf-atompub-protocol-14.txt'. 64 pages. Other: HTML version, XML version. Also: the -14 vs. -13 diff version format and the ATOMPUB Status Pages. Revision History notes: typos; removed "The language context is only significant for elements and attributes declared to be "Language-Sensitive" by this specification. "; "Successful member creation is normally indicated with a 201 ("Created") response code." removed "normally" from that sentence (9.2); Added "Media Link Entries are represented as Atom Entries and appear in the Collection." to 9.6; said that an app:accept value of "entry" is equivalent to "application/atom+xml;type=entry"; double-check spec terms; Member Entry Resource -> Entry Resource; Added MLE, Entry Resource and Media Resource terms defs; 6.1 para split; 10.1 collection paging, rewrote for clarity; 13.1.1 app:edited rewrote for clarity/conflict; text for GETting entries and cache handling; 4: Typo: "And Media Resources IRIs", s/Resources/Resource/; consensus call: 'application/atomsvc+xml', extension is .atomsvc; DRY app: categories; make it clear the app:draft support is optional whether or not the value is sent; 9.2: put related ideas together into paragraphs.; 10: partial list editing; security: use elharos text; app:edited: tweak text suplied by ari; create a section for workspaces and move the descriptive text there; Moved rfc2818 to non-normative references. Added the W3C note on lost updates as a reference. I-D Tracker. Status is Last Call; see the IESG discussion.

  • [February 26, 2007] The Atom Publishing Protocol. Edited by Joe Gregorio (IBM) and Bill de hOra (Propylon Ltd). February 9, 2007, expires August 9, 2007. IETF Network Working Group. Internet Draft 'draft-ietf-atompub-protocol-13.txt'. 59 pages. Other: HTML version, XML version. Also: the -13 vs. -12 diff version format and the ATOMPUB Status Pages. Revision History notes: "Added Lisa's verbiage. Folded in James' Atom Format media type 'type' parameter spec. Updated document references to be more consistent, added URLs to some, and shortened up their anchors. Debugged rnc."

  • [December 27, 2006] The Atom Publishing Protocol. Edited by Joe Gregorio (IBM) and Bill de hOra (Propylon Ltd). December 10, 2006, expires June 13, 2007. IETF Network Working Group. Internet Draft 'draft-ietf-atompub-protocol-12.txt'. 57 pages. ID Tracker. Other: HTML version, XML version. Also: the -12 vs. -11 diff version format and the ATOMPUB Status Pages.

  • [September 12, 2006] Last Call I-D. The Atom Publishing Protocol. Edited by Joe Gregorio (BitWorking, Inc) and Bill de hOra (Propylon Ltd). September 05, 2006, expires March 9, 2007. IETF Network Working Group. Internet Draft 'draft-ietf-atompub-protocol-10.txt'. 51 pages. ID Tracker. Other: HTML version, XML version. See also the diff with v-09 and ATOMPUB Status Pages. "The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format (RFC 4287). The protocol supports the creation of arbitrary web resources and provides facilities for: (1) Collections: Sets of resources, which can be retrieved in whole or in part; (2) Service: Discovering and describing Collections; (3) Editing: Creating, updating and deleting resources. The Atom Publishing Protocol uses HTTP methods to edit and author Member Resources as follows: [a] GET is used to retrieve a representation of a known resource; [b] POST is used to create a new, dynamically-named, resource; [c] PUT is used to update a known resource; [d] DELETE is used to remove a known resource. Along with operations on Member Resources the Atom Protocol defines Collection resources for managing and organizing Member Resources. Collections are represented by Atom Feed documents and contain the IRIs of, and metadata about, their Member Resources. There are two kinds of Member Resources - Member Entry Resources and Media Resources. Member Entry Resources are represented as Atom Entries. Media Resources MAY have representations in any media type. A Media Link Entry is a Member Entry that contains metadata about a Media Resource. Collections, represented by Atom feeds, contain entries. Those entries contain the Member Entry and Media Resources IRIs of the Collection. A Collection can contain any number of entries of either kind. In the diagram of a Collection below there are two entries. The first contains the IRI of a Member Entry Resource. The second contains the IRIs of both a Media Resource and a Media Link Entry Resource, which contains the metadata for that Media Resource..." From Appendix C (Revision History): V10 incorporates "PaceRemoveTitleHeader2, PaceSlugHeader4, PaceOnlyMemberURI,PaceOneAppNamespaceOnly, PaceAppCategories, PaceExtendIntrospection, UseElementsForAppCollectionTitles3, renamed Introspection to Service, lots of good editorial suggestions, updated media example with slug, moved xml conventions to convention sections, renamed XML related Conventions to Atom Publishing Protocol Documents, added auth header to examples, consolidated definition of all resource types into the model section, added IANA registration information for application/atomcat+xml."

  • [June 23, 2006] "Atom Threading Extensions." Edited by James M. Snell (IBM WebAhead Development Lab). IETF Internet Draft. Announcement. Reference: 'draft-snell-atompub-feed-thread-12.txt'. May 25, 2006, expires November 26, 2006. 13 pages. See the I-D Tracker for versions. James Snell, a member of IBM's WebAhead development lab, reported that the Internet Engineering Steering Group (IESG) has approved the "Atom Threading Extension" specification as a Proposed Standard. It's now in the RFC Editor queue awaiting final edits and its very own RFC number. The "Atom Threading Extensions" document describes a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format (RFC 4287). The specification defines an 'in-reply-to' extension element, used to indicate that an entry is a response to another resource. The element MUST contain a "ref" attribute identifying the resource that is being responded to. The element is not unlike the references and in-reply-to email message headers defined by RFC 2822. However, unlike the in-reply-to header, the "in-reply-to" element is required to identify the unique identifier of only a single parent resource. If the entry is a response to multiple resources, additional "in-reply-to" elements MAY be used. A new 'replies' link relation is also defined: an Atom link element with a rel attribute value of "replies" may be used to reference a resource where responses to an entry may be found. If the type attribute of the atom:link is omitted, its value is assumed to be "application/atom+xml". A "replies" link appearing as a child of the Atom feed or source element indicates that the referenced resource likely contains responses to any of that feed's entries..."

  • "The Atom Publishing Protocol." Edited by Joe Gregorio (BitWorking, Inc) and Bill de hOra (Propylon Ltd). February 01, 2006, expires August 05, 2006. IETF Network Working Group. Internet Draft 'draft-ietf-atompub-protocol-08.txt'. 41 pages. See the announcement and ID Tracker. Other: HTML version, XML version, -08 vs -07 diff. "The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format (RFC4287)." From Appendix C, 'Revision History': added infoset ref; added wording re IRI/URI; fixed URI/IRI; next/previous fixed as per Atom LinkRelations Attribute; incorporated: PaceEditLinkMustToMay; PaceMissingDraftHasNoMeaning, PaceRemoveMemberTypeMust, PaceRemoveMemberTypePostMust, PaceTitleHeaderOnlyInMediaCollections, PacePreserveForeignMarkup, PaceClarifyTitleHeader, PaceClarifyMediaResourceLinks, PaceTwoPrimaryCollections.

  • "The Atom Publishing Protocol." Edited by Joe Gregorio (BitWorking, Inc) and Bill de hOra (Propylon Ltd). January 01, 2006, expires July 5, 2006. IETF Network Working Group. Internet Draft 'draft-ietf-atompub-protocol-07.txt'. 40 pages. ID Tracker. "The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format specification (IETF RFC #4287)." From Appendix C, 'Revision History': updated Atom refs to RFC 4287; incorporated PaceBetterHttpResponseCode; PaceClarifyCollectionAndDeleteMethodByWritingLessInsteadOfMore; PaceRemoveAcceptPostText; PaceRemoveListTemplate2; PaceRemoveRegistry; PaceRemoveWhoWritesWhat; PaceSimplifyClarifyBetterfyRemoveBogusValidityText; PaceCollectionOrderSignificance; PaceFixLostIntrospectionText; PaceListPaging; PaceCollectionControl; element typo in Listing collections para3 (was app:member-type, not app:list-template); changed post atom entry example to be valid. Dropped inline use of 'APP'. Removed nested diagram from section 4. Added ed notes in the security section.

  • "APP Service Description Format." By Robert Sayre October 25, 2005, expires April 28, 2006. IETF Network Working Group. Internet Draft 'draft-sayre-atompub-protocol-outline-01.txt'. 9 pages. "This memo presents an XML format used to describe Atom Publishing Protocol services. These services typically expose one or more groupings of resources. On a blogging service, for example, each grouping might represent a distinct blog and associated resources. Many Atom Publishing Protocol applications require a basic resource layout in order to ease configuration requirements. XML documents are organized hierarchically, but XML does not differentiate between elements serving as structural divisions and elements serving as structural properties. This specification defines two elements which outline the structure of APP services, and defines minimal user agent conformance rules. The specification includes a normative RELAX NG Compact schema."

  • "The Atom Publishing Protocol." Edited by Joe Gregorio (BitWorking, Inc) and Bill de hOra (Propylon Ltd). October 27, 2005, expires April 30, 2006. IETF Network Working Group. Internet Draft 'draft-ietf-atompub-protocol-06.txt'. 41 pages. "The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format." Version -06: Added in PaceCollectionControl. Fixed all the {daterange} verbage and examples so they all use a dash. Added full rnc schema. Collapsed Introspection and Collection documents into a single document. Removed {dateRange} queries. Renamed search to list. Moved discussion of media and entry collection until later in the document...

  • "The Atom Publishing Protocol." Edited by Joe Gregorio (BitWorking, Inc) and Bill de hOra (Propylon Ltd). IETF Network Working Group, Internet Draft. Reference: 'draft-ietf-atompub-protocol-05.txt'. October 11, 2005, expires April 14, 2006. Updates the previous draft of May 09, 2005. 42 pages. See the diff against version -04. Versions: see the I-D Tracker. See also HTML and XML. Version -05: "Added diagrams and description to model section. Incorporates PaceAppDocuments, PaceAppDocuments2, PaceSimplifyCollections2 (large-sized chunks of it anyhow: the notions of Entry and Generic resources, the section 4 language on the Protocol Model, 4.1 through 4.5.2, the notion of a Collection document, as in Section 5 through 5.3, Section 7 'Collection resources', Selection resources (modified from pace which talked about search); results in major mods to Collection Documents, Section 9.2 'Title: Header' and brokeout para to section 9.1 Editing Generic Resources). Added XML namespace and language section. Some cleanup of front matter. Added Language Sensitivity to some attributes. Removed resource descriptions from terminology. Some juggling of sections." Unofficial draft-ietf-atompub-protocol-06 (Section 9 uses atom:updated for the ordering of collections).

  • [September 09, 2005] "Atom Link No Follow." By James M. Snell [WWW]. IETF Network Working Group. Internet-Draft. Reference: 'draft-snell-atompub-feed-nofollow-00.txt'. August 2005, expires February 2, 2006. 7 pages. HTTP scheme URI namespace name: http://purl.org/atompub/nofollow/1.0. An initial individual IETF Internet Draft has been published for "Atom Link No Follow," presenting a mechanism that allows Atom feed publishers to express preferences for how an Atom consumer should processe Atom links and Content-By-Reference. It thus conveys information to applications consuming Atom documents how they should handle links and referenced content contained within the feed. For example, a publisher may include an enclosure link within a feed but may not wish for applications to automatically download the enclosed file when it processes the feed; or, the publisher may not wish to allow applications to archive or index the enclosure in any way. The follow, index and archive attributes introduced herein provide the means for publishers to express these preferences. The x:follow attribute indicates whether applications should automatically attempt to follow links and referenced content (e.g., boolean, whether or not enclosure links should be automatically downloaded, etc). A value of 'no' indicates that applications should not attempt to automatically resolve the referenced resource — rather, the application should wait until a user explicitly requests the resource to be resolved. The x:index attribute indicates whether applications should index links and referenced content. The x:archive attribute indicates whether applications should archive the targets of links and content references..."

  • [September 09, 2005] "Atom Entry Expiration: Specifying Expiration Timestamps for Atom Entry Metadata." By James M. Snell [WWW]. IETF Network Working Group. Internet-Draft. Reference: 'draft-snell-atompub-feed-expires-01.txt'. August 2005, expires February 2, 2006. 8 pages. This document specifies a mechanism that allows the expression of expiration timestamps and maximum age properties for information content within the Atom Syndication Format. The mechanism defines two mutually exclusive extension elements that may be used to specify either an exact instant that the information content of an atom:entry expires, or a maximum age from the moment specified by an entries atom:updated element. When an atom:feed, atom:entry or atom:source contains an 'expires' or 'max-age' extension element, the information content of the contained element is considered to be 'time constrained'. Time constrainted information content is considered to be either 'active' or 'expired'. The default state is 'active'. When the age (calculated in milliseconds from the moment specified by the atom:updated element) exceeds the value specified by the 'max-age' extension, or when the moment specified by the 'expires' extension elements passes, the state of the time constrained information content MUST be considered to be 'expired' and no longer valid. It is strongly recommended that implementations either discard 'expired' information content or otherwise warn users that the information content has expired. The mechanism defined herein MUST NOT be used to support the caching of Atom documents and MUST NOT be used to schedule when a client should revisit/refresh local copies of Atom documents. Specifically, the 'expires' and 'max-age' extension elements are relevant only to the informational content within an atom:entry and are not relevant to the Atom Feed and Entry Documents in which they happen to appear..."

  • "Feed History: Enabling Incremental Syndication." By Mark Nottingham (BEA Systems) [WWW]. IETF Network Working Group. Internet-Draft: 'draft-nottingham-atompub-feed-history-04'. September 1, 2005, expires March 5, 2006. Changes in version -04: [1] fh:stateful -> fh:incremental, with appropriate changes in text; [2] more explicit cardinality information; [3] implications of fh:prev being an Absolute URI spelled out; [4] more explicit white space handling; [5] added Acknowledgements section. "Syndication documents (e.g., those in formats such as Atom and RSS usually only contain the last several entries in a larger channel (or 'feed') of information. Often, consuming software keeps copies of all entries that have been previously seen, effectively keeping a history of the feed's contents. However, not all feeds benefit from this practice; in some, previous entries are not relevant to the current contents of the feed. For example, it's not desireable to keep history in this manner with a 'top ten' feed; showing old entries would imply that the previous number one is now number eleven, and so forth... This document specifies a mechanism that allows feed publishers to give hints as to the completeness of a feed, and a means of retrieving 'missed' entries from a partial, or incremental, feed. Although it refers to Atom normatively, the mechanism described herein can be used with similar syndication formats, such as the various flavours of RSS." Later versions: see Datatracker.

  • "XHTML Microformats for the Atom Publishing Protocol." By Robert Sayre [WWW]. IETF Network Working Group. Internet-Draft: 'draft-sayre-atompub-xhtml-micro-00.txt'. September 3, 2005, expires March 7, 2006. 32 pages. "Atom Publishing Protocol [APP] client implementations require a fair amount of ancillary server-provided data in order to provide a smooth user experience. Rather than invent a plethora of new XML formats, this specification chooses to present a number of XHTML profiles, colloquially known as 'microformats'... hCat is an XHTML profile for encoding the three standard attributes of Atom category elements. By providing a definition list containing encoded category information, servers can present clients with a list of known categories in an XHTML definition list. hCat also allows description of endpoints for category editing through a simple HTTP-based protocol... HTTP provides response codes which indicate the success or failure of a given request, but does not go into great detail on textual diagnostics for the end-user. hError is an XHTML profile that encodes error information intended for the end-user..." See also: Microformats. Later versions: IETF datatracker lookup.

  • Cooked! The Atom Syndication Format. Edited by Mark Nottingham [WWW] and Robert Sayre [WWW]. Preliminary draft contributions from Tim Bray, Mark Pilgrim, and Sam Ruby; Norman Walsh provided the Relax NG schema. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-10'. July 11, 2005, expires January 12, 2006. 56 pages. XHTML and HTML, both usefully hyperlinked. Appendix C 'Change Log' identifies these changes in version -10: (1) capitalize "Atom Document" consistently; (2) fix atom:feed/atom:logo; (3) fix link hreflang/alternate in atom:feed; (4) add more acknowledgements; (5) expand security section; (6) clarify IRI processing.

  • "Feed License Link Relation." Edited by James M. Snell [alt jasnell@gmail.com]. IETF Network Working Group, Internet Draft. Reference: 'draft-snell-atompub-feed-license-00.txt'. July 02, 2005, expires January 02, 2006. 6 pages. "This document specifies a mechanism that allows the feed publishers the ability to associate copyright licenses with feeds and entries. Licenses associated with feeds and entries using these mechanisms MAY or MAY not be machine readable and are intended to communicate the various rights and obligations others may have with regards to given resource. specification defines one new Atom link relation type to be registered in the IANA Registry of Link Relations as defined by Atompub version -10." According to the August 09, 2005 posting: "As a reminder, the license extension provides a link relation for associating a copyright license with a feed or entry. The most common use case will be to associate creative commons licenses with feeds." See also relLicense microformat.

  • "Feed Index: Enabling Ordered Entries in Atom." By James M. Snell [WWW]. IETF Network Working Group. Internet Draft: 'draft-snell-atompub-feed-index-00.txt'. July 19, 2005, expires January 20, 2006. "This memo presents a mechanism that allows feed publishers to establish a numeric sorting index for the entries contained within a feed."

  • The Atom Syndication Format. Edited by Mark Nottingham [WWW] and Robert Sayre [WWW]. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-09. June 07, 2005, expires December 9, 2005. 53 pages. ID tracker. See Atom Specification Sent to IESG for Final Review, a communication between Paul Hoffman and Scott Hollenbeck on submission of the Atom version -09 draft to the IESG for final review, following changes made during and after the IETF Last Call. Note from Tim Bray to 'atom-syntax@imc.org' list June 08, 2005, speaking in "co-chair-mode": "This is what we consider our final product, and what we'll be taking forward through the IETF process; stand by for further news on that. Perhaps more important, this means that it's time to focus 100% of our time on the protocol work." Note the Timing Guide for Atom Implementers.

  • Atom Feed Autodiscovery. Edited by Mark Pilgrim (IBM) and Phil Ringnalda. IETF ATOMPUB Working Group. Reference: Internet Draft 'draft-ietf-atompub-autodiscovery-01.txt'. May 10, 2005, expires November 11, 2005. 14 pages. This document specifies a machine-readable method of linking to an Atom feed from a HyperText Markup Language (HTML) or Extensible HyperText Markup Language (XHTML) document, using the <link> element. See also the HTML and -01/-00 diff. See also pre-draft version -02.

  • "The Atom Publishing Protocol." Edited by Joe Gregorio (BitWorking, Inc) and Robert Sayre (Boswijck Memex Consulting). IETF Network Working Group, Internet Draft. Reference: 'draft-ietf-atompub-protocol-04.txt'. May 09, 2005, expires November 10, 2005. Updates the previous draft of March 18, 2005. 36 pages. See also HTML and XML. Version -04 is reorganized, adding ladder diagrams and SOAP interactions.

  • The Atom Syndication Format. Edited by Mark Nottingham and Robert Sayre. IETF Network Working Group. Internet Draft. Status: Last Call draft requested for approval as an IETF Proposed Standard. Reference: 'draft-ietf-atompub-format-08. April 18, 2005, expires October 20, 2005. 51 pages. See the diff against version -07. See the news story "IESG Issues Last Call Review for Atom Syndication Format as a Proposed Standard."

  • The Atom Syndication Format. Edited by Mark Nottingham and Robert Sayre. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-07. March 31, 2005, expires October 2, 2005. 49 pages. See the diff against version -06.

  • "The Atom Publishing Protocol." Edited by Joe Gregorio (BitWorking, Inc) and Robert Sayre (Boswijck Memex Consulting). IETF Network Working Group, Internet Draft. Reference: 'draft-ietf-atompub-protocol-03.txt'. March 18, 2005, expires September 19, 2005. Updates the previous draft of September 21, 2004. 20 pages. See also the color-coded diff version comparing version -03 to version -02. This version incorporates two Pace documents: (1) PaceSliceAndDice3: "Large Atom collections need to be accessible in small chunks. This proposal gives servers a way to slice the collection into subcollections, and it gives clients a way to dice those slices for their own needs. This method efficiently supports clients with or without persistent state."; (2) PaceIntrospection: Older versions of the AtomAPI had a file called the Introspection file; this file listed all of the different facets that a site supported. Real world experience has shown that this is a needed part of the API and this Pace reintroduces the concept with some minor changes."

  • The Atom Syndication Format.. Edited by Mark Nottingham and Robert Sayre. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-06. March 12, 2005, expires September 13, 2005. 48 pages. Updates the version -05 draft of January 26, 2005. Change log has 35 entries. See the HTML and diff against version -05. See also the End-game progress note from Tim Bray.

  • "The Atom Syndication Format." Edited by Mark Nottingham and Robert Sayre. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-05. January 26, 2005, expires July 27, 2005. This Internet Draft version -05 contains clarifications on "Securing Atom Documents" (use of the W3C Digital Signatures and Encryption specifications). It also provides a new informative Appendix B 'Collected RELAX NG Compact Schema' (RNC) prepared by Norman Walsh.

  • "The Atom Syndication Format." Edited by Mark Nottingham and Robert Sayre. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-04'. January 10, 2005, expires July 11, 2005. "Atom is an XML-based document format intended to allow lists of related information, known as 'feeds'. Feeds are composed of a number of items, known as 'entries', each with an extensible set of attached metadata. For example, each entry has a title. The primary use case that Atom addresses is the syndication of Web content such as Weblogs and news headlines to Web sites as well as directly to user agents. However, nothing precludes it from being used for other purposes and kinds of content. Details of communication protocols between software agents using Atom can be found in the Atom Protocol specification..." From IETF (ephemeral URL) http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-04.txt. See also the diff file relative to 'draft-ietf-atompub-format-04.txt'.

  • The Atom Syndication Format. Edited by Mark Nottingham (WWW). IETF Network Working Group. Internet Draft: 'draft-ietf-atompub-format-02'. September 5, 2004, expires March 06, 2005. 29 pages. "Atom is an XML-based document format intended to allow lists of related information, known as 'feeds', to be synchronised between publishers and consumers. Feeds are composed of a number of items, known as 'entries', each with an extensible set of attached metadata. For example, each entry has a title. The primary use case that Atom addresses is the syndication of Web content such as Weblogs and news headlines to Web sites as well as directly to user agents. However, nothing precludes it from being used for other purposes and kinds of content. Details of comunication protocols between software agents using Atom can be found in the Atom Protocol specification. This version -02 I-D adds a new section on Securing Atom Documents, with reference to the W3C/IETF specifications for 'XML-Signature and Syntax Processing' and 'XML Encryption Syntax and Processing.' It also adds a section on Identity Constructs: 'An Identity construct is an element whose content conveys a permanent, universally unique identifier for the construct's parent. Its content must be an absolute URI that is universally unique; i.e., it must not change over time, even if the parent feed or entry element is relocated, migrated, syndicated, republished, exported or imported'..."

  • The Atom Syndication Format. Edited by Mark Nottingham (WWW). IETF Network Working Group. Internet Draft: 'draft-ietf-atompub-format-01'. July 17, 2004, expires January 15, 2005. 27 pages.

  • "The Atom Publishing Protocol." Edited by Joe Gregorio (BitWorking, Inc) and Robert Sayre (Boswijck Memex Consulting). IETF Network Working Group, Internet Draft. Reference: 'draft-ietf-atompub-protocol-02.txt'. September 21, 2004, expires March 22, 2005. 22 pages. See also the color-coded diff version comparing version -02 to version -01. "This memo presents a protocol for using XML (Extensible Markup Language) and HTTP (HyperText Transport Protocol) to edit content. The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources belonging to periodically updated websites. The protocol at its core is the HTTP transport of Atom-formatted representations. The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources. Using the common HTTP verbs provides a pattern for working with all such Web resources: (1) GET is used to retrieve a representation of a resource or perform a read-only query; (2) PUT is used to update a known resource; (3) POST is used to create a new dynamically-named resource; (4) DELETE is used to remove a resource. The Atom format is documented in the Atom Syndication Format Internet Draft.

  • The Atom Publishing Protocol. Edited by Joe Gregorio (BitWorking, Inc, WWW) and Robert Sayre (Boswijck Memex Consulting, WWW). IETF Network Working Group. Internet Draft: 'draft-ietf-atompub-protocol-01.txt'. July 1, 2004, expires December 30, 2004. 20 pages.

  • Atom Feed Autodiscovery. Edited by Mark Pilgrim (International Business Machines Corporation). IETF Network Working Group. Internet Draft: 'draft-ietf-atompub-autodiscovery-00.txt'. August 17, 2004, expires February 15, 2005. 14 pages.

Articles, Papers, News, Technical Reports, Proposals

  • [October 31, 2008] "Hierarchy Extensions to Atom Feeds." Edited by Nikunj Mehta [WWW] and Colm Divilly [WWW] (Oracle). Posted October 31, 2008 to the atom-syntax list; with followups. Also available in HTML format. This specification defines a mechanism to create and remove AtomPub collections using the AtomPub protocol as well as to express hierarchies of feeds within the Atom Syndication Format. Many applications provide their data in the form of syndicated Web feeds using formats such as Atom (RFC 4287 = Nottingham, M., Ed. and R. Sayre, Ed., The Atom Syndication Format, December 2005) in order to enable application integration. Applications may also manipulate the contents of these data feeds using protocols such as AtomPub (RFC 5023 = Gregorio, J. and B. de hÓra, The Atom Publishing Protocol, October 2007). A key requirement for application data feeds is the ability to dynamically create new Collections and identify relationships among such feeds and Collections. This specification defines a mechanism for identifying hierarchical master-detail relations among data feeds so that consumer applications can perfrom standard AtomPub operations on them. A hierarchical master-detail relation of an Entry to a Feed implies the detail Feed is created when the master Entry is created and the Feed is removed when the Entry is removed. The Entry is called the "master entry" and the Feed is called "detail feed". This relationship allows a client to use AtomPub to create a new Collection by posting an Entry to an existing Collection... Protocol Model: Hierarchy extensions to Atom specify operations for creating, updating, and removing AtomPub Collections using existing AtomPub methods and extensions to Atom syntax. Feed Classification: AtomPub defines Feed, Entry, and Collection resources in the Atom syntax; the hierarchy extensions to Atom are designed for use with unmodifiable Atom Feeds as well as with AtomPub Collections. The extensions in this specification define two specialized kinds of Feeds — master Feed and detail Feed. Both are represented as Atom Feed Documents. A master Feed is a container for master Entires. Each master Entry contains a child Feed, which can be any logical Feed. The kind of child Feed's metadata identifies the kind of new Entries that it can accept. The child Feed is created when the master Entry is created and the child Feed is removed when the master Entry is removed. A master Feed MAY itself be a child of another master Feed..." Editors' note: "We'd like to discuss the draft below that introduces extensions for Atom and AtomPub to deal with hierarchies of feeds and the programmatic creation and removal of AtomPub Collections. This draft defines a mechanism for identifying hierarchical master-detail relations among data feeds so that consumer applications can perform standard AtomPub operations on them. A hierarchical master-detail relation of an Entry to a Feed implies the detail Feed is created when the master Entry is created and the Feed is removed when the Entry is removed. The Entry is called the 'master entry' and the Feed is called 'detail feed'. This relationship allows a client to use AtomPub to create a new Collection by posting an Entry to an existing Collection..."

  • [August 01, 2008] "Discussion Document: Revising the OAI-ORE Profile of Atom." By Michael Nelson, Robert Sanderson, and Herbert Van de Sompel. This discussion document relates to "ORE User Guide: Resource Map Implementation in Atom," published in draft form on June 02, 2008. Herbert Van de Sompel (Los Alamos National Laboratory, Research Library) writes: "As a result of feedback that was provided over the past few weeks, both via this list, in private communications, and via the blogosphere, we have made a bold move to compile a Discussion Document that outlines a proposal for a significantly different ORE Atom serialization... We understand this proposal comes very late in the ORE process that is expected to deliver 1.0 specification by the end of September 2008. Your feedback to this proposal is absolutely crucial. Please use the ORE Google Group to share your insights..." Summary from the discussion document: "This document describes a possible revision of the serialization of Resource Maps in Atom. The core characteristics of the revision are: (1) Convey ORE semantics in Atom as add-ons/extensions to regular Atom Feeds by introducing explicit ORE relationships instead of by according ORE-specific meaning to pre-defined Atom relationship values as is the case in the current 0.9 serialization. (2) Express an ORE Aggregation at the level of an Atom Entry not an Atom Feed; there are no ORE-specific semantics at the Feed level. Best practice in the Atom community regarding the use of Atom for specific applications is to define metadata extensions and new relationship types. The current ORE Profile of Atom has not taken this approach. Instead it uses e.g. existing, generic Atom relationships to represent specific ORE relationships. GData makes extensive use of '@rel' attributes and external metadata elements that are extensions to the basic Atom-defined ones. For example, the YouTube Atom Entry links related videos to a separate Atom feed (relative to the entry) with a specially defined '@rel' attribute value... Also, the Liverpool/HP ORE experimentation project (foresite) reported problems in determining which information available for an Aggregation to map to native Atom elements, and which to map to embedded 'rdf:Description' elements. This is especially true when the Atom element can only occur once, yet the predicate in RDF can occur multiple times... The functionality of the Atom Publishing Protocol deemed of essential importance for leveraging ORE Aggregations, is geared towards the Atom Entry level... The ORE Google Group discussions revealed the need to convey all Aggregations available from a repository in a variety of Feeds available from the repository. For example, subject-based Feeds, most recent-Feeds, monthly Feeds, my personal Feed, etc... See also Peter Keane 'OAI-ORE and Atom'.

  • [July 24, 2008] "It's Called AtomPub." By Tim Bray, From Ongoing (Blog). July 17, 2008. "Recently, I was asked for feedback on some technology being built inside Sun which was said to rely on 'Atom Pub/Sub'. In related confusing news, more than one big company has talked about 'Rolling out APP'. Branding matters. So we took it up on the Atom Protocol mailing list and, for what it's worth, the community of implementors has agreed that we're all going to refer to the protocol specified in RFC 5023 as [case-sensitive, camelCase] 'AtomPub' and nothing else. Please co-operate... Next, we need a logo. Might Google or Microsoft, who are taking the lead in rolling out AtomPub-based services, be willing to dedicate some design talent to a candidate or two? Do any indie hackers with graphics skills want to play?... See backgound at: Now it gets ugly: Atompub vs. AtomPub, and the thread.

  • [July 24, 2008] "Atomic Monday." By Tim Bray, From Ongoing (Blog). July 07, 2008. "Herewith some evidence, for the general tech public, that Atompub is a big deal, and for the Atomistas, some interesting developments... It's an Atompub Future. Let's see; Microsoft is using Atompub for... well, everything, pretty much. Google has been for a while, and that's now leveraging Salesforce.com. Oh, and the Kool Erlang Kids are getting into the act: Atom-PubSub module for ejabberd (Hmm, I dislike 'Atom PubSub' and all its orthographic variations). And then there are things like AtomServer.... Atom-Multipart: To post an image (or any other bit-blob) with Atompub, you HTTP-POST it; the server stores it and creates a synthetic Atom entry for metadata about it. Then if you want to update the metadata, you have to PUT that. So Joe Gregorio, based on his work at Google, is proposing 'atom-multipart'; the idea is use pack up your bit-blob and an Atom entry full of metadata, and push 'em at the server in a MIME multipart package... Everyone seems to like the idea, the Atom-protocol mailing list is chewing it over, the IETF seems to think it's appropriate for the standards track, and I've volunteered to be the consensus referee (which is probably poetic justice since I'm obviously going to have to implement the sucker in mod_atom)...

  • [July 17, 2008] "Annotating the Web with Atom. Open Up the Whole Idea of User Participation." By Uche Ogbuji (Partner, Zepheira, LLC) and Eric Larson (Developer, YouGov). From IBM developerWorks (July 08, 2008). What we call Web 2.0 came from several related impulses to make the Web more valuable. One of those impulses is for a 'read-write Web'. Most of the time we use the Web as mere spectators. There are a few publishers (writers) and innumerable readers. More and more people do have the tools to write the Web, but again they are usually just writing to a few small areas where they have control. Many would like to see a more balanced Web where more people can contribute and can do so more widely. The most important Web 2.0 developments (weblogs, weblog comments, wikis, and forums, for example) and resource or media sharing sites (del.icio.us, Flickr, YouTube, and Digg, for example) make it more of a read-write Web. Still there is room to go further. In this article we introduce a subtle but effective approach for widening the space in which average users can write the Web... Comments on weblogs and such sites are a suitable and fairly well-understood starting point for annotating the Web. They associate snippets of text with a URL, which might be a weblog entry, a news article, a media resource, or something similar. There is a limited concept of typing for such comments (grouping them by nature or source). Some are merely pointers to other primary URLs, such as weblog track-backs and ping-backs... The key [...] is to build on the scaffolding of well-established standards. The Atom group of standards, in particular, has a lot to offer. The Atom Threading Extension extends the core Atom syntax with a means of providing context for an Atom entry. Simply, the Atom Threading Extension allows you to declare an entry or feed as being a response or reply to some resource. This extension makes creating feeds for comments and threaded conversations rather obvious... The Atom syntax provides a format for expressing Web annotations. The Atom Publishing Protocol ("AtomPub") provides a framework for building annotation services. In this article we present an annotation server that's no more than a slightly specialized AtomPub server. The only extra requirement is that Atom entries contain a threading element that will be indexed for later queries. The general ideas were explored in the Annotea project of W3C staffers in the early part of this decade. The framework of our approach is the established Atom syntax and the Atom protocol. The code we've presented is just one possible flavor, and you'll find there are many languages and libraries you can use to craft your own implementation. The big lesson is that RESTful architecture makes it pretty easy to build on existing work, and that once you get used to thinking that way, you start focusing less on narrow solutions such as weblog comments, and more on expansive ideas such as annotating the Web..."

  • [July 02, 2008] "AtomServer: The Power of Publishing for Data Distribution." By Bryon Jacob and Chris Berry. From InfoQueue (July 02, 2008). "Consider this: you work for a company with a federation of fully independent web sites, implemented in half a dozen different programming languages, on several different platforms. Each independent website has its own database system and schema, and is managed by teams with varying skill sets, located in eight sites throughout the United States and Europe. And the company is growing. Your job? Enable these disparate systems to share crucial data conveniently and rapidly amongst themselves. Your design criteria are: (1) High Traffic Capability: the service would need to move approximately 1M pieces of data a day at launch; (2) Transactional Correctness: the service must be accurate as the authoritative source of data for all clients; (3 )Resiliency: the service must be easy to upgrade with seamless data republishing when formats change; (4) Loose Coupling: with so many systems, each must be able to manage themselves independently; (5) Adoption: the system must have a low barrier to entry for clients implemented in a variety of languages -- Java, C#, PHP, Ruby, and ColdFusion; (6) Adaptability: the system must support many different types of data and be extensible to add new types of data on demand... We were faced with exactly this problem about a year ago at Homeaway.com... it didn't take long to recognize two design tenets. First, that a distributed, publish-subscribe service is a great way to address resiliency and loose coupling of subsystems, and second, that building RESTful services (as opposed to heavyweight protocols like SOAP) is a natural solution for systems that need high scalability, extensibility, and ease of adoption. These two principles led us directly to Atom (a RESTful publishing protocol) and to a new breed of data service called an Atom Store. We've spent the last year implementing an Atom Store for Homeaway. And from that real-world implementation we have extracted the open source Atom Store framework, named AtomServer, described in this article... AtomServer is in live production use at our company, handling more than a million requests a day, with several million entries in our store. Building on a RESTful specification such as Atom while leveraging the design of existing services like GData have ensured a solid foundation on which to build. We hope that you will pick up a copy and tell us what you think...

  • [June 30, 2008] AtomTriples: Embedding RDF Statements in Atom. Edited by Mark Nottingham (WWW) and Dave Beckett (WWW). Credits to Hong Zhang. IETF Network Working Group, Internet Draft: 'draft-nottingham-atomtriples-00'. June 30, 2008; expires January 1, 2009. See I-D Tracker. "This specification describes AtomTriples, a set of Atom (RFC 4287) extension elements for embedding RDF statements in Atom documents (both element and feed), as well as declaring how they can be derived from existing content. Statements can be embedded directly as RDF/XML using the at:md element at the feed or entry level. Additionally, a feed can declare that specific Atom elements (or extensions) can be parsed into RDF statements using the 'at:feedmap' element (for metadata attached to a feed) or an 'at:entrymap' element (for metadata attached to entries). The semantics of a property that appears in both places (e.g., in a feed-level 'at:md' as well as derived from a 'at:feedmap') is undefined; presumably, they would be added to the model as two separate statements. Likewise, the mechanics of combining metadata from multiple instances of the same entry, or from multiple feed documents, is out of the scope of this specification. Unless specified otherwise, AtomTriples elements may contain foreign markup, which should be handled according as it is in the Atom syndication format. RDF statements can be directly embedded in Atom feeds and entries as RDF/XML using the 'at:md' element. The 'at:md' element may occur as a child of atom:feed or atom:entry, and contains any number of RDF statements which must be serialised as RDF/XML. It may occur in a given context any number of times. The subject of these statements is, by default, the value of the atom:id element in the same context ('atom:element' or 'atom:feed'). However, this behaviour may be overridden by specifying the subject attribute. After the subject is determined, the contents should be processed as a 'propertyEltList', per the W3C Recommendation "RDF/XML Syntax Specification (Revised)." When present, the subject attribute indicates how to derive the RDF subject of statements sourced from the element it is attached to. It must contain a URI which must be interpreted as a link relation; the first such occurrence of an atom:link element in the same context as its parent element with that relation (in lexical order) will indicate the URI to use as the subject. All XML elements in this specification use the the namespace URI 'http://purl.org/syndication/atomtriples/1'.

  • [June 26, 2008] "OAI-ORE and Atom." By Peter Keane (Peter Keane's Miscellanea). "There have been some interesting conversations lately regarding the OAI-ORE specification, especially its use of Atom as a serialization format. I have great respect for the folks behind OAI-ORE, and their success with OAI-PMH is well-deserved. But the world has changed quite a lot since OAI-PMH was released and filled a pressing need: we had the RSS wars (RSS 2.0 won), we had the REST vs. WS-* wars (REST won), then some very smart folks came along to basically moot the RSS wars with a well-specified but simple format called Atom. Based on REST principles and doing syndication one better by also specifying a 'write back' protocol, Atom seems to embody what's best about web architecture. Not only is it a great specification, with all kinds of applicability outside of its blog-oriented upbringing, but the process of creating the spec was, and continues to be open. I cannot begin to express how useful and enlightening it has been to participate in ongoing discussions on Atom mailing lists, and to peruse the 'back issues' to gain clarity on design decisions that guide my implementation. I have little doubt that Atom, a more widely supported specification than OAI-PMH, could supplant OAI-PMH, and I think that would be a good thing... Atom is quite good for the uses it was intended, and for many uses outside of that (I note particularly Google's GData services). But it is also almost perfectly suited to the use cases for which the Open Archives Initiative was originally chartered. What is needed is guidance — essentially, an implementors guide to Atom for these use cases. Do we need another spec for that — perhaps not. But why not channel that library/archive expertise into Atom implementation guidelines... Note also: Real World REST with Atom/AtomPub, by Peter Keane... DASe is a lightweight PHP5/(MySQL|PostgresQL|SQLite) web framework for creating, cataloging, and sharing collections of digital images, audio, video, and documents. DASe is suitable for anything from a small, personal collection of images and mp3s all the way to an enterprise-level repository of heterogeneous digital assets. DASe provides a full REST-based web services interface which can expose and ingest XML documents in a simple DASe-specific key-value schema OR Atom feed schema. DASe is an open source project..." According to the Google Code web site: "DASe was developed by Liberal Arts Instructional Technology Services at the University of Texas at Austin. The current installation at UT Austin includes over 4 million pieces of metadata about 300K+ audio, video, images, and document files. Public beta release is scheduled for December 2007."

  • [June 07, 2008] "AtomPub Multipart Media Creation." Edited by Joe Gregorio [WWW] (Google). IETF Internet Draft. May 1, 2008, expires November 2, 2008. 9 pages. Intended status: Standards Track. See the ID Tracker. This specification defines how an Atom Publishing Protocol collection should process multipart/related requests and also defines how a service announces that it accepts multipart/related entities. The Atom Publishing Protocol (RFC 5023) defines Media Collections and how to create a Media Resource by POSTing the media to the Media Collection. RFC 5023 does not define handling multipart/related (RFC 2387) represenatations nor does it specify how the acceptance of such representations should be advertised in the Service Document. This specification covers both the processing and the Service Document aspects of handling multipart/related content... The primary objective of multipart/related POSTs is to reduce round- trips for creating Media Resources. There will be three round trips in the typical Media Resource creation scenario; POST of the media, GET of the Media Link Entry, and subsequent PUT of the updated Media Link Entry. This specification reduces that to just a single round-trip by allowing the client to package up the media and the associated Media Link Entry into a single multipart/related representation which is POSTed to the Media Collection. The design of the handling of multipart/related representations was aimed at backward compatibility, that is for non-multipart/related aware clients to fully function. A second aim was to retain and utilize the expressiveness of the current app:accept element in the Service Document. The last aim was to ease the burden on clients by allowing the mulitpart representation to be constructed in an order that was convenient for the client... The applicability of multipart/related representations to AtomPub Collections is restricted to just creating new entries in Media collections. It does not specify the creation or use of a resource that supports a GET to return the multipart/related representation nor does it specify the creation or use of a resource that supports a PUT of a multipart/related representation. [source]

  • [June 03, 2008] Associated Press: Content Enrichment and NewsMap Frequently Asked Questions. April 14, 2008 (or later). "Content enrichment is the process of adding descriptive information to news content such as text stories, photos, videos or graphics. This information (metadata) describes the subjects in a piece of news content (e.g., sports, politics, etc.) and the famous people mentioned (e.g., politicians, entertainers, etc.) AP's content enrichment program currently focuses on text. It has three steps: (1) Members send text stories to AP; (2) AP adds metadata to the content; (3)AP returns the metadata to the members (as feeds) for use in their own systems and business arrangements... How does AP receive my content for markup? AP technical staff will work with you to establish a specialized 'feed' of your stories into the content enrichment system. The format of this feed is built on the ATOM specification. ATOM is a kind of markup language (XML) that tags news content with various definitions. For example, it can be used to tag the main structures of a story — the headline, byline, etc. This tagging makes it easy for AP to feed members' copy into the enrichment systems. AP's iATOM is a variant of ATOM. It contains the full text of stories, rather than just a link to the full text. In AP Content Enrichment, iATOM is the preferred type of feed... the 'ATOM specification' is AP's technical specification/description for iATOM, our preferred method for receiving content..." Reference from Mark Nottingham. Similarly ('AP Atom'), from "Extending AP's Mission into the Digital Age": "Editors can create customized news and multimedia feeds based on specific search criteria in AP Exchange. The content is supplied as XML in the AP ATOM format along with additional proprietary metadata. WebFeeds Manager is a free program provided by the AP to manage and route AP Web Feeds to content management systems. It supports text, photos, audio, graphics and video..."

  • [June 02, 2008] "ORE User Guide: Resource Map Implementation in Atom." Version 0.9. June 02, 2008. Editors (OAI Executive): Carl Lagoze (Cornell University Information Science) and Herbert Van de Sompel (Los Alamos National Laboratory). Editors (ORE Technical Committee): Pete Johnston (Eduserv Foundation), Michael Nelson (Old Dominion University), Robert Sanderson (University of Liverpool), Simeon Warner (Cornell University Information Science). Licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. "This implementation guide describes serialization of ORE Resource Maps using the Atom Syndication Format (RFC 4287). A detailed examination of the mapping of ORE Data Model concepts to the Atom Syndication Format is known as the ORE Specification: Representing Resource Maps Using the Atom Syndication Format.. The purpose of this document is to provide guidance to application developers on how to implement and interpret the Specification. Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. OAI-ORE introduces the notion of Resource Maps that describe an Aggregation. A Resource Map identifies an Aggregation, it asserts the finite set of constituent resources (the Aggregated Resources) of the Aggregation, and it can express types and relationships pertaining to the Aggregation and its Aggregated Resources. Each Aggregation may be described by one or more Resource Maps, each of which must have exactly one representation that is a serialization of the Resource Map according to a specific format. .." See (1) ORE version 0.9 Table of Contents, and (2) the announcement: "Open Archives Initiative Announces Public Beta Release of Object Reuse and Exchange Specifications."

  • [June 01, 2008] "Atom Link Relation: Discuss." Edited by Peter Saint-Andre (XMPP Standards Foundation). IETF Internet Draft. May 27, 2008, expires November 28, 2008. The "Atom Syndication Format" defined in IETF RFC 4287 is an XML-based document format that describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata. Such metadata can include links to other resources, which are primarily defined by Uniform Resource Indentifiers (URI) or Internationalized Resource Indentifiers (IRI). A link can be secondarily defined as partaking in a specific kind of relationship to the document. This "Atom Link Relation: Discuss" specification defines a new link relation, ("discuss") which can be used to point to Internet resources where a person can actively engage in a multi-party discussion or conversation about the document itself or the primary topic covered by the document. Any Atom link element with a 'rel' attribute value of "discuss" is used to reference an Internet resource where multi-party discussion of the feed, entry, or source can occur. In the terminology of this specification, such a resource is called a "venue". Such venues might include, but are not limited to, the following: Electronic mail discussion lists; Network news discussion boards (NNTP); Internet Relay Chat channels (IRC); Web-based forums accessible via the Hypertext Transport Protocol (HTTP); Multi-user chat rooms based on the Extensible Messaging and Presence Protocol (MUC and XMPP); Multi-user chat rooms based on the Message Session Relay Protocol (MSRP); Voice or video conference rooms based on the Session Initiation Protocol (SIP)... The use of the "discuss" relation enables a person who receives an Atom feed or entry to discover a venue where the person can engage in a conversation about the feed or entry with interested others. This use case is not currently addressed by any existing Atom link relation, which to date address use cases such as reading background material (the "related" relation) or following other people's comments (the "comments" relation) rather than actively engaging in a conversation or discussion about the feed or entry. It is expected that a link relation of type "discuss" would be presented to a human user in such a way that the user would understand that following the link would result in joining an active discussion venue rather than accessing a static resource. One example shows an Atom entry that contains numerous links related to the ejabberd XMPP server project, including links to an XMPP chatroom, an email discussion list, a web forum, and two web pages with background information..."

  • [May 28, 2008] "Not Turtles, AtomPub All the Way Down." By Dare Obasanjo. Blog. May 28, 2008. "Last month Anil Dash commented on recent announcements about Microsoft's strategy around Web protocols (saying) "AtomPub has become the standard for accessing cloud-based data storage. From Google's GData implementation to Microsoft's unified storage platform that includes SQL Server, Atom is now a consistent interface to build applications that can talk to remote databases, regardless of who provides them. And this milestone has come to pass with almost no notice from the press that covers web APIs and technology..." I don't think the Atom publishing protocol can be considered the universal protocol for talking to remote databases given that cloud storage vendors like Amazon and database vendors like Oracle don't support it yet. That said, this is definitely a positive trend... Microsoft is using AtomPub as the interface to a wide breadth of services and products. [Microsoft's] FeedSync, one of the core parts of the Live Mesh platform, isn't really AtomPub but it does use the Atom syndication format so I count that as a win for Atom+APP as well. As time goes on, I hope we'll see even more products and services that support Atom and AtomPub from Microsoft. Standardization at the protocol layer means we can move innovation up the stack. We've seen this happen with HTTP and XML, now hopefully we'll see it happen with Atom + AtomPub. Finally, I think it's been especially cool that members of the AtomPub community are seeing positive participation from Microsoft, thanks to the folks on the Astoria team who are building ADO.NET Data Services (AtomPub interfaces for interacting with on-site and cloud based SQL Server databases). Kudos to Pablo, Mike Flasko, Andy Conrad and the rest of the Astoria crew..."

  • [May 15, 2008] "Yahoo SearchMonkey Is Out of Its Cage." By Clint Boulton. From eWEEK (May 15, 2008). " SearchMonkey comprises three layers: First, Yahoo partner publishers, such as The New York Times, Yelp, eBay and StumbleUpon, share structured data with Yahoo. Third-party developers then access this content through semantic markup languages, such as microformats and RDF, standardized XML feeds, Web services APIs, and page extraction, to create widgets. These widgets will include navigational links, reviews, contact information and locations to provide enhanced search listings. Finally, developers make these apps available in a gallery on Yahoo, from which consumers can grab them to customize their searches. According to the online SearchMonkey Guide: Site Owners have web sites containing the data retrieved by SearchMonkey applications. To be used by SearchMonkey applications, this data must be structured. Site owners can make structured data available to Yahoo! in any of the following ways: (1) Atom Feeds: Site owners push data to Yahoo! by submitting Atom feeds. (2) Markup: Site owners markup up their web pages with microformats or RDFa/eRDF, extracted by Yahoo! when crawling these URLs. Microformats are the leading established standard for web page markup. RDFa and eRDF are also widely accepted standards. Since these are all open standards, marking up your pages using any of these formats makes your content more easily reusable. (3) Web Services: Site owners create custom Web Services that provide access to their structured data... The Adjunct Syntax Specification (with Relax NG Compact Syntax specification) describes a method called DataRSS for embedding arbitrary metadata within feed vocabularies, including RSS, Atom, IDIF, and others..."

  • [May 05, 2008] " Full Validation of Atom Feeds Containing Extensions." By Makoto Murata and Hisashi Miyashita. Technical Report. Updated May 05, 2008 or later. See the associated files. MURATA Makoto writes: "I wrote a note about full validation of Atom feeds containing extensions such as OpenSearch and Google Calendar. Hisashi Miyashita, my co-author, implemented an NVDL validator for such validation." The RELAX NG schema (hereafter atom.rnc) in RFC 4287 (The Atom Syndication Format) does not provide full validation of atom feeds containing extensions. Rather, the schema focuses on top-level constructs of atom feeds; it skips extension elements and attributes, even when extension elements further contain constructs of atom feeds. Some specifications (e.g., RFC 4685 (Atom Threading Extensions) for atom extensions provide schemas for extension elements and attributes. These extension schemas focus on extension elements and attributes, and are typically written in RELAX NG. However, such extension schemas are not referenced from atom.rnc. As a result, these schemas do not provide full validation of atom feeds containing extensions. They are useful for documentation, but they are not usable for validating atom feeds. One might wonder whether atom.rnc and extension schemas can be combined to form a single RELAX NG schema against which atom feeds containing extensions are fully validated. To the best of our knowledge, our earlier work is the only example of such combined schemas. We combined a variation of atom.rnc and three schemas for atom extensions thereby successfully providing full validation. However, we do not believe that this all-in-one approach provides a reliable basis for full validation of atom and its extensions. The all-in-one approach requires that (1) schema authors understand schema customization techniques (e.g., the combine feature of RELAX NG) very well, (2) they avoid pitfalls caused by wildcards, and (3) they understand customization points of all schemas to be combined. In this document, we advocate the use of Namespace-based Validation Dispatching Language (ISO/IEC 19757-4) for full validation of atom feeds containing extensions. Schema authors for atom extensions first create schemas dedicated to the extensions. They then create NVDL scripts for combining these schemas and atom.rnc. Controlled by NVDL scripts, the NVDL engine decomposes atom feeds containing extension elements or attributes into (1) extension-free atom and (2) extensions so that (1) and (2) are validated separately. As an example, an NVDL script for Google Calendar is presented. This NVDL script reveals that embedded atom entries in Google Calendar XML documents have validation errors..."

  • [April 02, 2008] "Google Data APIs Patent License [for Atom, AtomPub, extensions]." By Joe Gregorio. Google Blog. 2008-04-01. Joe Gregorio, Technical Program Manager of the Google Data APIs Team wrote: "We've always encouraged other developers to adopt Atom, the Atom Publishing Protocol, and the extensions that Google has created on top of those standards, but we realized the issue of patents may have held back some adopters. Well, those concerns end today as we are giving a no-charge, royalty-free license to any patents we have that you would need to implement Atom, AtomPub, or any of those extensions. The exact license text: 'Subject to the terms and conditions of this License, Google hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this License) patent license for patents necessarily infringed by implementation (in whole or in part) of this specification. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the implementation of the specification constitutes direct or contributory patent infringement, then any patent licenses for the specification granted to You under this License shall terminate as of the date such litigation is filed.' Now the official way to announce such a license for specifications under the IETF is to register them in the IETF IPR Disclosure Database; you can read the disclosures yourself in the IETF Disclosure Database. Google's extensions are also covered by this patent license, and you can find a link to them on the bottom of the authentication schemes AuthSub and ClientLogin on our core Google Data extensions and Common Elements, and on [several] Data APIs... We hope this will encourage sites who want to expose APIs for things like photos, videos, calendar, or contacts to reuse our schemas where they can, rather than reinventing the wheel." In this connection, note Mark Nottingham's muse upon the possible defect in some of the blanket non-assert declarations, in his blog "Moving the Goalposts: 'Use' Patents and Standards" — "It's become quite fashionable for large IT shops to give blanket Royalty-Free licenses for implementation of core technologies, such as XML, Web Services and Atom... IT folk see these licenses, nod their heads and relief, and assume that all is well; they can use this technology in their projects without fear of at least a handful of big, bad companies coming to get them. That's not the case. You see, most of these licenses are restricted to the implementation of this technology, not its use. This clears the people who actually write the code that implements the [XML, Web Services, Atom] parsers, processors and tools, but it doesn't help the folks that use those things. In effect, the vendors are pooling together their IP and giving each other free cross-licenses on chosen technologies — calling a truce, if you like — but not including their users..." See also Mark Nottingham's blog.

  • [April 15, 2008] "Apache Abdera: Atom, AtomPub, and Java." By Stefan Tilkov and James Snell. From InfoQueue (April 15, 2008). "The Apache Abdera project, an open source Atom Syndication and Atom Publication Protocol implementation currently still in its incubation phase, has recently reached its 0.40 milestone, an important step towards graduation [as an Apache project]. Snell: "While Atom and AtomPub certainly began life as a way of syndicating and publishing Weblog content, it has proven useful for a much broader range of applications. I've seen Atom being used for contacts, calendaring, file management, discussion forums, profiles, bookmarks, wikis, photo sharing, podcasting, distribution of Common Alerting Protocol alerts, and many other cases. Atom is relevant to any application that involves publishing and managing collections of content of any type... Abdera is an open source implementation of the Atom Syndication Format and Atom Publishing Protocol. It began life as a project within IBM's WebAhead group and was donated to the Apache Incubator in June 2006. Since then, it has evolved into the most comprehensive open-source, Java-based implementation of the Atom standards.. Abdera has been part of the Apache Incubator for long enough. While there are still some details to work out, I would very much like to see Abdera graduate to its own Top Level Project at Apache, and become host to a broad range of Atom-based applications." Diephouse: "Look to some of the public services out there: most of the APIs for Google are based on AtomPub. Microsoft is moving toward it for web APIs too. These services are all going beyond just blogs. AtomPub goes beyond public web APIs as well — I've noticed that many enterprises are starting to use AtomPub for some of their internal services as well. Both AtomPub and SOAP/WSDL give you a way to build a service for others to use. But AtomPub takes a fundamentally different approach to helping users implement services. It implements constraints which give new types of freedom. Because the data format is constrained — every entry has a title, entry, id, and content/summary — I can use an Atom feed from any type of application and get some useful information out of it... Abdera includes support for developing/consuming AtomPub services, an IRI library, a URI template library, unicode normalization, extensions for things like XML signature/encryption, GData, GeoRSS, OAuth, JSON and more. One of the cool new things in the latest release are a set of 'adapters' which allow you to have an AtomPub service without any coding by storing entries in JDBC, JCR or the filesystem...

  • [March 14, 2008] "HTTP Header Linking." Edited by Mark Nottingham. IETF Internet Draft: 'draft-nottingham-http-link-header-01'. March 14, 2008, expires September 15, 2008. See also the ID Tracker. "This memo clarifies the status of the Link HTTP header and attempts to consolidate link relations in a single registry. A means of indicating the relationships between documents on the Web has been available for some time in HTML, and was considered as a HTTP header in RFC 2068, but removed from RFC 2616, due to a lack of implementation experience. There have since surfaced many cases where a means of including this information in HTTP headers has proved useful. However, because it was removed, the status of the Link header is unclear, leading some to consider minting new application-specific HTTP headers instead of reusing it. This document seeks to address these shortcomings. Additionally, formats other than HTML — namely, Atom (RFC 4287) — have also defined generic linking mechanisms that are similar to those in HTML, but not identical. This document aims to reconcile these differences when such links are expressed as headers. This straw-man draft is intended to give a rough idea of what it would take to align and consolidate the HTML and Atom link relations into a single registry with reasonable extensibility rules. In particular: (a) it changes the registry for Atom link relations, and the process for registration; (b) it assigns more generic semantics to several existing link relations, both Atom and HTML; (c) it changes the syntax of the Link header — in the case where extensions are present. The Link entity-header field provides a means for describing a relationship between two resources, generally between that of the entity associated with the header and some other resource. An entity may include multiple Link values. The Link header field is semantically equivalent to the 'link' element in HTML, as well as the 'atom:link' element in Atom. The title parameter may be used to label the destination of a link such that it can be used as identification within a human-readable menu... Link Relation Registry: This specification is intended to update Atom s a way of indicating the semantics of a link. Link relations are not format-specific, and must not specify a particular format or media type that they are to be used with. The security considerations of following a particular link are not determined by the link's relation type; they are determined by the specific context of the use and the media type of the response. Likewise, a link relation should not specify what the context of its use is, although the media type of the dereferenced link may constrain how it is applied. New relations may be registered, subject to IESG Approval, as outlined in RFC 2434..."

  • [March 05, 2008] "Aggregate RSS and Atom Information Using XQuery: Speed Your Merging and Filtering of RSS and Atom Info With XQuery." By Martin Brown. From IBM developerWorks (March 05, 2008). "The Really Simple Syndication (RSS) and Atom standards provide XML structures of items for a variety of different uses. The most common use for both RSS and Atom feeds is as the data dissemination format to promote Weblogs and news sites. The RSS and Atom feeds contain relatively small amounts of information. Thus, you can easily download the files and reduce the load on the Web servers rather than supply all of the information normally distributed when the user views a full page of blog posts. In addition, the RSS and Atom files also contain more detailed classification information such as author, title, subject and keyword tagging information to help identify and organize the data within the feeds. In this article we look at the basics of XQuery processing of RSS and Atom feeds to turn a single feed into an HTML document. We then produce a more complete solution for outputting the information in a format that suits your needs, including sorting, merging multiple feeds and even handling different feed and source information types. XQuery offers a flexible method to process XML files. Some find this method is easier to follow syntactically. Certainly some XQuery abilities, such as the flexibility to create to a single intermediary XML document that you can reparse to handle different sources and input formats, help solve some issues experienced when you process XML files..."

  • [March 04, 2008] "Microsoft Bets on Atom Publishing Protocol for Web APIs." By Hartmut Wilms. From InfoQueue (March 04, 2008). "[As reported by David Treadwell on New and Updated Windows Live Platform Services] Microsoft is switching from the "Web Structured, Schema'd & Searchable (Web3S)" protocol to the Atom Publishing Protocol (AtomPub) for services offered by Microsoft's Live Platform on the Web. David Treadwell, Corporate Vice President of Microsoft's Live Platform Services, discussing the Windows Live Platform Services, notes that "Microsoft is making a large investment in unifying our developer platform protocols for services on the open, standards-based Atom format (RFC 4287) and the Atom Publishing Protocol (RFC 5023). At MIX we are enabling several new Live services with AtomPub endpoints which enable any HTTP-aware application to easily consume Atom feeds of photos and for unstructured application storage. Or you can use any Atom-aware public tools or libraries, such as .NET WCF Syndication to read or write these cloud service-based feeds." AtomPub will also be used as the standard protocol for ADO.NET Data Services, codename "Project Astoria". According to Dare Obasanjo: "The fact is when we listened to the community of Web developers the feedback was overwhelmingly clear that people would prefer if we worked together with the community to make AtomPub work for the scenarios we felt it wasn't suited for than Microsoft creating a competing proprietary protocol. We listened and now here we are. If you are interested in the technical details of how Microsoft plans to use AtomPub and how we've dealt with the various issues we originally had with the protocol, I suggest subscribing to the Astoria team's blog and check out the various posts on this topic by Pablo Castro..." Adapting the standardized Atom Publishing Protocol is in line with Microsoft's new interoperability principles, support for REST and Syndication in WCF, and the high extensibility and pluggability of the ASP.NET MVC Framework..."

  • [January 29, 2008] "Atomojo Atom Publishing Protocol (APP) Server 0.7.0 Release Available." Reported by Alex Milowski. XML-DEV. January 29, 2008. "Atomojo's APP implementation has been coming along quite nicely and release 0.7.0 is quite stable: 'This atomojo Google Code project contains both an Atom Publishing Protocol (APP) server and client. While both are intended to be used together, as they implement a standard protocol, they can be used with other APP-enable applications. The client is a Firefox plugin that contains an XPCOM component for interacting with the Atom Publishing Protocol (APP). Atomojo's APP implementation has been coming along quite nicely and release 0.7.0 is quite stable. Here's a short list of some features: full APP implementation; hierarchical feeds; XQuery support; large binary support; full REST interfaces for administration; integration with external authentication services; indexing of Atom category elements; retrieval of entries and feeds via categorization; metadata services for context and query by term and term value. The Atomojo server provides a uniform way to store multiple feeds and manipulate them with the Atom Publishing Protocol (APP). Feeds are organized hierarchically and indexed by their categorization. It provides both metadata feeds for getting context information about feeds as well as pulling a feed for each categorization stored in the database. The server runs on top of a restlet.org engine and uses a rest-style URI architecture for its feeds. Feed are organized hierarchically just like a file system but they are store in an XML database called eXist. In addition to eXist, there is a metadata index that is stored in an embedded Derby database. This index stores information about what feeds contain what entries as well as information about categorization. Once the server is started, you can get the service introspection document by a GET on the server root...'

  • [January 05, 2008] "Convert Atom Documents to JSON. Avoid Loss of Important Data and Context When You to Convert from Atom to JSON." By James Snell. From IBM developerWorks (January 05, 2008). "Converting an Atom document to JSON might, at first, appear to be a fairly straightforward task. Atom is, after all, just a bit of XML and XML-to-JSON conversion tools are widely available. However, the Atom format is more than just a set of XML elements and attributes. A number of subtle details can make proper handling of Atom difficult. When you convert an Atom document into JSON, you take a great deal of information-rich content and serialize it into a drastically simplified form. You can more easily use the simpler form of that content in environments where parsing and properly processing the XML is prohibitively difficult. The main challenge to this process is to ensure that important data and context is not lost in the translation. This article describes those issues and demonstrates a mechanism implemented by the Apache Abdera project to convert Atom documents into JSON and produces a result that is readable, usable, and complete... With a data format as rich and capable of Atom, serializing to a format as simple and basic as JSON can be problematic at best. While there have been several very good attempts at getting it right, until an effort is made to produce a standardized transformation, application developers need to be prepared to deal with multiple, potentially incompatible serializations that vary broadly in quality. The technique described here is just one of several possible approaches..."

  • [January 02, 2008] "Atom Syndication Format Tombstones." Edited by James M. Snell [WWW]. IETF Internet Draft 'draft-snell-atompub-tombstones-03.txt'. January 2, 2008, expires July 5, 2008. 7 pages. Intended status: Standards Track. The "Atom Tombstones" specification has been updated after several months of dormancy. The specification defines mechanisms by which Atom Feed publishers can explicitly indicate that specific Atom Entries have been removed from an Atom feed. The "atom:deleted-entry" element may appear as a child of atom:feed to represent an Atom Entry that has been removed from the feed. The "atom:deleted-entry" element must contain one "atom:id" element whose value specifies the atom:id of the entry that has been removed. The "atom:deleted-entry" element MAY contain one atom:when element whose value is an RFC 3339 "date-time" specifying the instant the entry was deleted. An uppercase "T" character must be used to separate date and time, and an uppercase "Z" character must be present in the absence of a numeric time zone offset... Atom Feed Documents may contain any number of "atom:deleted-entry" elements... As specified in RFC 4287, Atom processors should be aware of the potential for spoofing attacks where an attacker publishes atom:entry or "atom:deleted-entry" elements using the same atom:id values as entries from other Atom feeds. An attacker may attempt to trick an application into believing that a given entry has either been removed from or added to a feed. To mitigate this issue, Atom processors are advised to ignore "atom:deleted-entry" elements referencing entries that have not previously appeared within the containing Feed document and should take steps to verify the origin of the Atom feed before considering the entries to be removed... See also the Atom Syntax list thread.

  • [December 27, 2007] "ORE User Guide: Resource Map Implementation in Atom." Edited by Carl Lagoze (Cornell University Information Science) and Herbert Van de Sompel (Los Alamos National Laboratory). Produced by members of the Open Archives Initiative, Object Reuse and Exchange (ORE). 10-December-2007. "Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. OAI-ORE introduces the notion of a Resource Map, which is a specialization of a named graph that asserts a finite set of resources (the Aggregated Resources), their types, intra-relationships, and relationships with resources external to this finite set (the external resources). A Resource Map Document is a machine-readable representation of a Resource Map. Although multiple serializations of Resource Maps are possible, the initial serialization is done using the Atom Syndication Format (RFC 4287. A detailed examination of the mapping of ORE Data Model concepts to the Atom Syndication Format is known as the Resource Map Profile of Atom. The purpose of this document is to provide guidance to application developers on how to implement and interpret the Resource Map Profile of Atom. We anticipate that the contents and guidance given in this document to evolve over time to reflect the best practices of the community.

  • [August 17, 2007] "A Standards-Based Approach to Using the Atom Publishing Protocol to Publish Common Alerting Protocol (CAP) Alerts." By James Snell. From IBM developerWorks (August 17, 2007). "The Atom Publishing Protocol, sometimes known as the Atompub protocol, is a mechanism to publish and manage collections of resources using the basic HTTP GET, POST, PUT, and DELETE operations. While originally designed as a way to post new entries to weblog software, the Atompub protocol is well suited as a way to manage nearly any kind of Web-based content. In this article, I present an example Java Web application that uses the Atom Publishing Protocol to publish and distribute CAP alerts. The Common Alerting Protocol (CAP) is a simple, standardized XML data format used by the United States Department of Homeland Security, the United States Geological Survey (USGS), the Government of Canada, and many other organizations to exchange information about a broad range of warnings and emergencies. The CAP standard defines a type of document called an alert, which is used to exchange information about geological, meteorological, public health and safety, rescue, law-enforcement, environmental, transportation, infrastructure, and terrorist warnings and events. Such alerts can be generated either manually by incident responders or automatically by monitoring and sensing equipment, and they can be distributed using a variety of means. Syndication formats such as Atom and RSS comprise one distribution channel for CAP alerts that's growing in popularity... In the example presented here, I use the Apache Abdera project to take advantage of Abdera's built-in support for digitally signed and encrypted documents. Abdera makes it easier to implement the Atom Publishing Protocol endpoint. Later, I'll show you how to use that endpoint to publish and manage alerts..." [The goal of the Apache Abdera project is to build a functionally-complete, high-performance implementation of the IETF Atom Syndication Format (RFC 4287) and Atom Publishing Protocol (RFC 5023) specifications.]

  • [August 06, 2007] "django-atompub: Implementation of Atom Format and Protocol for Django." By James Tauber. Software Announcement, posted to the 'atom-syntax' list. The Google Code django-atompub Project intends to be a full implementation of the Atom Syndication Format (IETF RFC 4287) and Atom Publishing Protocol for the Django web framework. The full set of RFC 4287 elements is now supported. The "User Guide to django-atompub" provides instructions for use. As of Revision 15, 'atom.py has' no dependency on Django itself, so it can actually be used outside of Django as a general Python library for generating Atom feeds. To generate an atom feed with django-atompub, firstly download 'atom.py' and put it somewhere in your python path. Then, create bridge class that will tie your models to the atom data model. This class should extend Feed in the above atom module and then implement a variety of methods to provide data to the feed generator. Aas to feed validation, RFC 4287 places certain constraints on combinations of elements and their contents. For example, [i] if a feed has no author, each of the entries must have an author — possibly in the source element; [ii] if no there is content, an entry must have alternate link; [iii] external content — i.e., content with a src attribute) requires the entry has a summary. By default, feeds are validated against these and many other constraints described in RFC 4287. This check greatly reduces the chance of producing an invalid atom feed. If a feed violates a constraint, an 'atom.ValidationError' will be thrown. In django-atompub, the Text, Person, Link, Category, Source, and Content Constructs are supported. The main Django project is also tracking this Google Code work. Note from the author (James Tauber): "Although the Django web framework has had Atom support for a while, it is incomplete and, for the most part, covers only those fields that Atom and RSS have in common. So I offered to implement full support for RFC 4287 in Django. The result is available at django-atompub on Google Code. The 'atom.py' module is actually independent of Django and so can be used as a general Python library for Atom feed generation. Support for the Atom Publishing Protocol — which is the main project delviverable is next..."

  • [July 24, 2007] Atom is Done: That's All, Then. By Tim Bray. From Ongoing [Blog] (July 24, 2007). The IESG has approved the "The Atom Publishing Protocol" specification as a Proposed Standard. Tim Bray, Co-Chair of the IETF Atompub Working Group, writes in his blog: "Atom is done. Now the editorial processes grind away and eventually the official specification of the Atom Publishing Protocol will be an RFC substantially identical to 'draft-ietf-atompub-protocol-17'. It will join RFC 4287 (The Atom Syndication Format) as the official products of the IETF Atompub Working Group. What's Next? Now we'll find out who's interested. The Atom feed format is a success; RSS isn't going away, but a steadily-increasing proportion of the world's new feeds are Atom 1.0. I personally think the protocol's going to be a big deal... [but] What Do We Call It? The term 'Atom' is hopelessly vague, and most people use it to refer the feed format, which is fine. We could say 'Atom Protocol' or 'APP' or 'Atompub'; let's see what shakes out..." Note from the IESG announcement: "The Atom Publishing Protocol HTTP-based protocol for publishing and editing web resources, and is particularly useful for (but not limited to) blogs. It supports ideas such as collections of multimedia items and categorization of items. It uses the Atom Format (RFC 4287) for its messages. The document went through many revisions and was discussed actively. There are already many implementations of the spec from a wide variety of vendors, and many of those have been shown to interoperate."

  • [July 03, 2007] Apache Module in C for the Atom Publishing Protocol. Tim Bray, Ongoing Blog "mod_atom". June 25, 2007. As summarized by Kurt Cagle: "Tim Bray recently announced his publication of a new Apache module, mod_atom, which will make it possible to use the Atom Publishing Protocol (APP) directly with the Apache HTTPD server. This is a pivotal achievement, and one that will rocket APP into daily use. APP uses Atom feed content and HTTP headers to build a publishing 'blog' system, though its uses extend considerably beyond the normal scope for blogging and could very well be a staple of most data publishing systems within the next few years." From the Ongoing Blog description: "An Apache Module provides code that gets linked into httpd, the Web server binary. There are hundreds [of modules]; a few are included with the server distro, but most aren't. Code in a module doesn't have to do anything like CGI, you're just a C subroutine that gets called with a package of details about the request and the current server state. Which can save some cycles... I think that the Atom Publishing Protocol is going to be a big enough part of the Web ecosystem that Apache, as perhaps the world's single most important piece of Web infrastructure, really ought to support it. Think of it as giving PUT something useful to do. What Does it Do? It implements all of the Atom Protocol, near as I can tell. There's no database: everything is persisted in files; entry paths look like /blogs/tim/atom/e/entries/2007/06/23/cat-pix. Since it blasts Atom Entries straight into files, it can easily (unlike most Atom protocol implementations) preserve foreign markup. It should run fine under any MPM, without concurrency issues. All the 'atom:id' values begin 'urn:uuid', so you could in principle move a whole publication from one server and directory to another. Those who have memories of me arguing bitterly against URNs in general and atom:id in particular can please restrain your snickering while I'm around. For the moment, mod_atom is just an Atom server, not a blog engine. Which is to say that it accepts and stores and updates and deletes the Atom Entries and generates feeds appropriately, but doesn't actually generate any HTML versions..."

  • [June 05, 2007] "Adding Resources to an Atom API Server: Use of the Atom Slug Header." By Nicholas Chase. From IBM developerWorks (June 05, 2007). "One advantage of the Atom Publishing Protocol is the ability to not only retrieve information, but also to add or edit information. The Atom Publishing Protocol works on the principle that you can accomplish everything you want to do through simple HTTP operations. You can read an item using the GET method, or add one to the system using the POST method. When you do, the response includes the URL for the new entry. In this tip, you learn to use Atom's Slug header to influence the final URL for this information. The example uses the Blogapps server, which supports draft 10 of the Atom Publishing Protocol 1.0 specification, but is applicable to any APP 1.0 compliant server. This can be handy for servers that do not automatically use the title for the URL, or in any situation in which you want more control over the URL that the server chooses. What if you wanted to control (or at least influence) the URL your server selects? The Atom API provides a specific header, Slug, that enables you to do that. The Slug header is named after the publishing industry's slug, or short name used to refer to articles. A server is not required to honor the Slug header, but if yours does, you can use it to control at least part of the URL provided to a new resource. [Note: As an application-level protocol for publishing and editing Web Resources using HTTP, APP supports creating, editing, and deleting of Entry and Media Resources: (1) GET is used to retrieve a representation of a known Resource. (2) POST is used to create a new, dynamically-named, Resource. When the client submits non-Atom-Entry representations to a Collection for creation, two Resources are always created — a Media Entry for the requested Resource, and a Media Link Entry for metadata about the Resource that will appear in the Collection. (3) PUT is used to edit a known Resource; it is not used for Resource creation. (4) DELETE is used to remove a known Resource.]

  • [May 22, 2007] "Signing, Encrypting, and Decrypting Atom: Abdera Meets Java Cryptography." By Nicholas Chase. From IBM developerWorks (May 22, 2007). "Atom is a great format for relaying information, but what about security concerns? XML Digital Signatures can ensure that data comes from a trusted party and that it in unaltered, and XML Encryption can obscure sensitive information from prying eyes. But how can you use these technologies without destroying Atom structures? This article shows you how digital signatures and encryption can easily mesh with Atom data using the Apache Abdera API. The article assumes that you are familiar with the concepts behind the Atom syndication format. You should also have at least a passing familiarity with the concepts behind XML security, though this isn't strictly necessary. We use fairly simple examples of using Atom data with both digital signatures, which verify both the sender and the integrity of the information, and encryption, which prevents unauthorized parties from obtaining sensitive information. To accomplish these tasks, we use the Apache Abdera project, which enables one to easily manipulate Atom data. Abdera also includes objects that make it possible to integrate easily with client side certificates, to automatically encrypt Atom data at the servlet level, and more..."

  • [May 07, 2007] "Simple Sharing Extensions for Atom and RSS." By Steven Lees. Atom Syntax Posting and Microsoft XML Developer Center Article. Steven Lees (CSA Concept Development Team, Microsoft) wrote on the Atom Syntax list: "I'm seeking feedback on a specification that works in conjunction with Atom. I'm part of the team at Microsoft that is developing Simple Sharing Extensions (SSE). Adding SSE information to a feed enables loosely coupled data synchronization between multiple endpoints that are sharing the feed. The original version of SSE supported RSS as a feed format, and I've just posted to the web the latest version of the spec, which adds a binding for Atom feeds. The SSE spec is designed so that an SSE-annotated Atom feed is valid and can be consumed by any feed reader, even if that reader doesn't participate in sync. The ability to sync data across endpoints in a loosely coupled way enables some interesting end user scenarios. Simplicity is one of the main design points for SSE, which means that the spec is suitable for implementation on relatively small devices as well as larger ones. The spec is released under a Creative Commons license, and our goal is to encourage a range of implementations of the spec for a wide variety of computing environments." Simple Sharing Extensions for Atom and RSS 0.93 overview: "The scope of Simple Sharing Extensions (SSE) is to define the minimum extensions necessary to enable loosely-cooperating applications to use XML-based container formats such as Atom and RSS as the basis for item sharing — that is, the bi-directional, asynchronous synchronization of new and changed items amongst two or more cross-subscribed feeds." See also the FAQ document.

  • [April 26, 2007] "Atom Will Change the World." By Charles F. I. Savage. Charlie Savage's Blog (April 26, 2007). "Its a rare day that a truly good standard comes along. Its an even rarer day that the standard get widely adopted. So the developers of Atom should stand up and take a bow: not only did they hit a home run with the Atom syndication format, they've done it again with the Atom publishing protocol... What is news is the surprisingly deep and capable technology platform Atom offers, making it suitable for a large range of applications well beyond blogging software. In fact I believe we're witnessing the birth of the next great technology standard, with Atom taking its place alongside HTML, HTTP and the underlying protocols that support the Internet... Atom is so useful because of the emergent properties that arise from its unique combination of: (1) A simple data model of collections that contain entries; (2) Careful selection of the most important metadata - author, update time, etc.; (3) Support of attached pictures, songs and video to entries; (4) Extensibility through XML namespaces; (5) A standard REST API that fully leverages HTTP; (6) Easy to read, short specifications that can be implemented in a good days worth of hacking. Starting with the data model, it turns out that modeling the world as collections that contain entries is awfully useful. Clearly this model works well for blogs, which are a collection of articles. But it also works across a vast range of domains, such as modeling records in tables, songs in collections, features on a map, items in a shopping cart, books in a library, etc. Then for each entry, Atom defines a small set of the most useful attributes... right off the bat Atom provides a universal way that computers can share a base level of information about whatever things they model. Atom then takes this a step farther by allowing custom information to be embedded via the use of XML namespaces. Thus you can use XHTML to embed a story, GeoRSS to embed coordinate information, rank extensions to embed rating information, threading extensions to embed comments, etc. Both the Atom syndication format and publishing protocol are simple to implement since they build off the strong foundation of provided by XML and HTTP. For the work I've done with MapBuzz, I had an Atom feed up in running in a couple hours and full support for the Atom publishing protocol in a day..."

  • [April 24, 2007] "Manage a Media Collection with the Atom Publishing Protocol." By Nicholas Chase. From IBM developerWorks (April 24, 2007). "You might know the Atom syndication format as a way to provide blog entry information, but did you know that in conjunction with the Atom Publishing Protocol, you can use it to manage media files? This article shows you how to create a Web-based media repository with Atom. The article assumes that you are at least marginally familiar with the Atom syndication format, and with HTML concepts such as forms. To follow the example, you'll need an application server that supports the Atom Publishing Protocol (APP). Roller is great, and even runs the blogs here at developerWorks, but the installation manual is 27 pages long; fortunately, Dave Johnson has put all the pieces together in the Blogapps server. To run the example application, you'll need a servlet- capable server. Blogapps includes Tomcat, so you can use that. If you choose to use a separate instance, you'll need to alter the 'server.xml' file to prevent port conflicts. The last step is to install the Apache Abdera package, selected to make the APP easier to use. You will create a servlet that uses the Atom Publishing Protocol to add media resources to an Atom collection, which is part of a workspace. To add each resource, you'll use a POST request that sends the file to a URI designated for that collection. When you do that, the server creates a corresponding media-link entry that refers to it. You can then extract the information about all of those items in an Atom feed, which you can then use to display the information on a Web page. The Atom protocol also makes use of the other HTTP methods. You'll use GET to query information, DELETE to delete it (of course) and PUT to edit existing information (if possible). The Atom Syndication Format, combined with the power of the Atom Publishing Protocol, offers a good way to manage your resources, the images, audio, or even text or xhtml..."

  • [April 20, 2007] "Recapping the Atom Publishing Protocol Interoperability Meetup." By DeWitt Clinton (Google Developer Programs). Blog (April 20, 2007). "Google had the privilege and pleasure of hosting the first-ever Atom Publishing Protocol interoperability meetup earlier this week in Mountain View, CA. The Atom Publishing Protocol is a specification that helps define the interactions between clients and servers that wish to read and write collections of documents via the web. Building upon the popular Atom Syndication Format, the Atom Publishing Protocol formalizes many of the mechanisms required for the exchange of rich and meaningful content via a process known as Representational State Transfer, known familiarly as REST. Nearing completion as an Internet Engineering Task Force (IETF) standard, the protocol is already seeing wide adoption, and the working group felt it was time to bring people together to see how the various existing implementations interacted with each other. Over twenty (20) representatives from organizations and companies far and wide (some hailing from all the way across the Pacific) made the trip to Mountain View for two days of interoperability testing. The meetup was open to anyone who has built client or server software that uses the protocol, and it was extensively blogged about and 'simulcast' over the Atom IRC channel for those who could not attend in person. Striking was the diversity of both the organizations in attendance (AOL, IBM, Google, Microsoft, Oracle, O'Reilly, Six Apart — to name just a few) and the wide variety in types of applications being built. And a special thanks to Tim Bray, co-chair of the Atom Publishing Protocol working group, for his tireless devotion to the standards process and for leading the group in making the most of our time together. And for the curious: how did Google's many implementations of the protocol do at interoperability? Well, authentication was a hurdle for most clients (the specification itself considers authentication to be an orthogonal concern), but beyond that our servers are relatively compliant and some of our client code is well along the way to full support for the protocol. Perhaps more importantly, Google is committed to continued support of the working group, and we intend to keep pace with the draft specifications as they are finalized..."

  • [April 19, 2007] "Atompub Interop Lessons." By Tim Bray. From Ongoing Blog (April 17, 2007). "The [Atompub Interop] results are summarized on the Wiki; what do they mean? Obviously, good news: The fact that people from this many places, most of whom had never met before, got together and were able to put that many check-marks on the grid, based on a protocol whose design is not quite frozen, verges on the miraculous... It's become pretty obvious that a pretty broad range of pieces of software can fairly claim to to be Atompub implementations. This is more obvious on the server than on the client side, partly because the implementations are more numerous and mature at this point. Some are clearly not general-purpose; for example, the O'Reilly people at the Interop event had what appeared to be a perfectly legal implementation; but you could only post DocBook XML to it. Which I can see being useful for them, but a vanilla blogging client probably won't work that well with it, out of the box... Technologies represented: Perl, Python, PHP, Ruby, Java, C#; DB2, Oracle, MySQL, Derby, flat files; Linux, Windows, OS X, Solaris. Spot the pattern? Sun and IBM and Oracle have working database-backed Atom stores. Microsoft and IBM, that we know of, have in-progress clients. Judging by my email, there are a bunch of startups hacking together one side or another of the protocol. Draw your own conclusions, but I think it's obvious..." See: (1) APP Client/Server Interop Grid; (2) APP Interop Event April 16-17, 2007.

  • [April 19, 2007] "Atom Publishing Protocol Interop a Success." By Keith Fahlgren. From O'Reilly News (April 17, 2007)."The first interoperability session for Atom Publishing Protocol implementations (both clients and servers) was a success. The best news was that many of the clients and servers were able to interoperate with little to no tweaking despite never having met before. Check out the (evolving) grid of success and failures for details. More than 20 implementors attended the event, held yesterday and today at Google, as well as Lisa Dusseault, the IETF Area Director for APP. The other positive news is that big industry players like AOL, Google, IBM, Microsoft, Oracle, and Sun are working on APP clients and servers and sent people to the interop event with interesting code. Google and IBM in particular sent a lot of folks. Some quick notes [excerpted]: (1) Two days of intense work didn't uncover big holes in the spec, which is nice. (2) Many of the servers are currently quite permissive because of differing conformance levels of clients in the wild today. This will hopefully change when the spec gets finalized and clients are updated. (3) Adding a second or third namespace — probably 'app:' and 'xhtml:', potentially 'rdf:' and others — to your Atom entries starts making your decisions on default namespaces more important for both clients and servers. (4) The clients and servers were implemented in a wide range of languages, showing that the spec is quite implementable (even by inexperienced mediocre programmers like myself) and that XML technologies are finally now accessible in all the modern languages, a relatively recent change XMLers sometimes forget. I remember seeing code Python, C#, Ruby, Java, XQuery, PHP, and Perl, but I may be leaving some out. (5) DeWitt Clinton of Google hinted that they've been quite successful at handling giant loads with their APP services. (6) From a more personal perspective, O'Reilly's own internal APP repository now has hundreds of books, thousands of articles, and hundreds of thousands of images, and is already driving some site improvements, like these dynamic Table of Contents pages. (7) Tim Bray posted some pictures on his blog "Interop Impressions and Pix"; see details in "Atompub Interop Lessons"...

  • [April 10, 2007] "Create a Multi-Section Atom Collection or Feed." By Nicholas Chase. From IBM developerWorks (April 10, 2007). "The Syfy Portal newsfeed has the potential to contain over 3000 archived news stories. Virtually nobody wants their feed reader to download all of these messages, especially since many of them are several years old. To solve that problem, the Atom specification allows for the necessity to send only a portion of the available information. It takes into account the fact that you don't always want to send all of your data to a requester, and provides a way to make this capability feasible. As feeds move beyond merely announcing new content on somebody's blog and into organizing data, you can easily find situations where you don't want your feed to include all of the available data. This tip shows you how to create an Atom feed that lets users page through it using "next" and "previous" links or buttons. It shows you how to implement this functionality using PHP, but the concepts are the same for any programming language..."

  • [December 27, 2006] "amplee: A Python Library Implementing the Atom Publishing Protocol." By Sylvain Hellegouarch. IETF atom-protocol List Announcement (December 11, 2006) An announcement was posted for the release of amplee 0.3.6 — called 'alpha', but "... you can be safe and use it already as it stands; it should soon move to beta." amplee is a Python implementation of the Atom Publishing Protocol (APP), as specified in draft 11 or later. amplee's aim is to provide an API close to the APP specification which can be used in any Python code, and HTTP handlers to make it easy to integrate an APP store into a web application. amplee has different levels and can be used in a number of ways: (1) At a minimum it's just a pure Python library implementing the Atom Publishing protocol. In that case the API model is almost a 1-to-1 mapping of the APP spec. Modules in the amplee.atompub package include [a] store: APP does not define the meaning of store. We use that concept to describe the outter envelop that carries related APP entities. A store is the layer between the underlying storage (database, filesystem, etc.) with APP entities; [b] service: amplee attaches a service entity to a store. A service also has a list of workspaces it handles; [c] workspace: a workspace belongs to one service and has a list of collections; [d] collection: amplee collection module allows CRUD operations to be made on members. (2) It has built-in members for common data type such as XHTML, audio formats (MP3, Ogg, Flac, WavPack) or Open Document Text format. (3) You can also use built-in storages to persist members of a collection. Currently supported: filesystem, subversion, zodb, and database backend via dejavu. amplee is distributed under the Creative Commons Attribution-ShareAlike2.5 License... See also the Atom Protocol Python Group.

  • [December 27, 2006] "Managing Content with the Atom Publishing Protocol." By Andrew Savikas (Director, Digital Content & Publishing Services, O'Reilly Media, Inc). Presented at XML 2006 (December 4-7, 2006, Boston, MA, USA). "While the Atom Publishing Protocol is gaining acceptance in online publishing, especially around blogging, it's also flexible enough to serve as a general-purpose 'content API' for O'Reilly Media's next-generation content architecture. At O'Reilly, we've used Atom to balance the need to be flexible in what content types are accepted (XML, HTML, PDF, Word, OpenOffice.org) with the equally important need to be predictable about how that content is made available to a variety of applications (Safari, SafariU, oreilly.com, print-on-demand). Content creators need not worry about the downstream needs of ever-changing applications, they just focus on creating DocBook XML, XHTML, or PDFs (along with associated images). In turn, those downstream applications needn't worry about the quality of the content available to them — it's guaranteed valid, with all referenced images present and accounted for. O'Reilly is using the Atom Publishing Protocol to implement a powerful abstraction layer separating content creation from content consumption, simplifying the workflow on both ends, and solidifying XML's role at the core of our content management and delivery strategy."

  • [December 12, 2006] "Getting to Know the Atom Publishing Protocol, Part 3: Introducing the Apache Abdera Project." By James Snelljasnell@us.ibm.com (Software Engineer, IBM). From IBM developerWorks (December 12, 2006). "Earlier articles in this series provided an overview of the Atom Publishing Protocol and described the various ways it is being utilized in real world applications. This article begins to demonstrate how you can start to implement Atom-enabled applications using a new open-source project, called Abdera, currently under incubation at the Apache Software Foundation. It covers the Feed Object Model, XPath and XSLT support, extension handling and incremental parsing model. The discussion assumes that you have read the Atom Format specification and that you are familiar with syndication in general. All of the examples are provided in Java code and a sample Eclipse project containing all of the code samples is provided for download... The Abdera project consists of a collection of individual modules. The core module defines what Abdera calls the "Feed Object Model", a set of interfaces used for parsing, creating and manipulating Atom documents that is modeled after the Atom Syndication Format specification. The two primary functions of Abdera's Feed Object Model are to make it easy to both produce and consume Atom Feed and Entry documents. Abdera's Feed Object Model interfaces follow the Atom Syndication Format schema very closely, making it natural for developers who are familiar with the RFC 4287 specification to produce valid Atom documents. However, it is important to point out that the implementation does not perform any validation of the input. For instance, RFC 4287 requires that all atom:entry and atom:feed elements contain exactly one atom:id element whose value is a normalized IRI. Abdera, however, does not throw an exception if a developer tries to create and serialize an entry or feed that does not contain an atom:id or that contains multiple atom:ids. Developers are responsible for ensuring that the documents they produce are valid. With the FeedValidator, you can check the validity of Atom documents. When the Abdera project was launched, the stated goal of the project was to provide functionally complete implementations of both the Atom Syndication Format and the Atom Publishing Protocol. Thus far, this series has provided a fair amount of coverage of the support for the Syndication Format and has illustrated how to produce and consume feeds. The next installment will cover the Atom Publishing Protocol client and server support that is still currently being implemented..."

  • [November 21, 2006] "Atom Bidirectional Attribute." By Jamed Snell. IETF Network Working Group, Internet Draft 'draft-snell-atompub-bidi-01' Said to be 'September 2006'. Tracker. Announced November 20, 2006. Note: Version -02 draft [December 06, 2006] has two significant changes: (1) drops the rlo and lro values; (2) specifies that UA's MAY right-align RTL text using the same rules defined for HTML. ['This I-D adds a dir attribute to Atom Common Attributes that is used to specify the base direction of text in Atom documents.'] IETF has released a level -01 Internet Draft for the 'Atom Bidirectional Attribute' specification. This draft updates the Atom Syndication Format by adding a new attribute that may be used to indicate the base directionality of directionally-neutral characters. The 'dir' attribute specifies the base direction of directionally- neutral text, as defined in the Unicode standard. Possible values for the attribute are 'ltr' and 'rtl' indicating 'left-to-right' and 'right-to-left' respectively, 'lro' and 'rlo' indicating explicit 'left-to-right' and 'right-to-left' overrides, or an empty string indicating that no base-direction is specified. If the 'dir' attribute is not specified, the value is assumed to be an empty string. The attribute can appear anywhere in an Atom document, except where it is explicitly forbidden. The direction specified by 'dir' applies to elements and attributes whose values are specified as being 'Language-Sensitive' as defined by Section 2 of RFC 4287. The attribute is inherited by descendent elements and may be overridden. The Unicode bidirectional control characters may also be used within attributes and element values to indicate the directionality of text. Implementers are reminded that unexpected results could occur when using both the 'dir' attribute and the Unicode control characters within a single document..."

  • [November 10, 2006] "Getting to Know the Atom Publishing Protocol, Part 2: Put the Atom Publishing Protocol (APP) to Work. Interact with Deployed Applications like Weblogs or Calendars." By James Snell. From IBM developerWorks (November 07, 2006). The previous installment in this series presented a brief walk-through of the Atom Publishing Protocol (APP). In accordance with the charter of the IETF's Atom Publishing Format and Protocol Working Group, the Atom Publishing Protocol is designed for the primary use case of publishing and management of weblog entries. It should come as no surprise, then, that many blogging software providers such as Google, SixApart, and Roller have already started to roll out preliminary support for the protocol. In early August of 2006, Google announced a long-awaited update to its hosted weblogging service. Among a number of other features, the service now supports the use of the Atom Publishing Protocol to create and edit posts. Creating a post is rather straightforward. The first thing you need to know is the URL of the Atom collection to which new entries will be sent. For Blogger, the Atom feed used to syndicate the content of blogs to feed readers and aggregators doubles as the Atom Publishing Protocol collection. To find the collection URI then, one needs only look at the alternate link in the header of their weblogs home page. This article presents a number of real-world Atom publishing implementations that are already deployed and in use by thousands of users. To support the examples provided, this article demonstrates the use of the open source Apache Abdera project to interact with various blogging, calendar, and data management services. The next installment of this series provides a detailed overview of the Apache Abdera project, including a walk-through of the Feed Object Model API and a range of features including XPath, XSLT transforms, content filtering, and XML Digital Signature support.

  • [October 17, 2006] "Getting to Know the Atom Publishing Protocol, Part 1: Create and Edit Web Resources with the Atom Publishing Protocol. Take an Introductory Walk Through the Basic Operation of the Protocol." By James Snell. From IBM developerWorks (October 17, 2006). The IETF Atom Syndication Format, or Atom 1.0 as it is known commonly, has since been deployed to millions of Web sites and is supported by every major syndication platform on the market. Today, just over a year later, work nears completion on the second of the two specifications: The Atom Publishing Protocol. The Atom Publishing Protocol is an HTTP-based approach for creating and editing Web resources. It is designed fundamentally around the idea of using the basic operations provided by the HTTP protocol (such as GET, PUT, and DELETE) to pass around instances of Atom 1.0 Feed and Entry documents that represent things like blog entries, podcasts, wiki pages, calendar entries and so on. Central to the Atom Publishing Protocol is the concept of collections of editable resources that are represented by Atom 1.0 Feed and Entry documents. A collection has a unique URI. Issuing an HTTP GET request to that URI returns an Atom Feed Document. To create new entries in that feed, clients send HTTP POST requests to the collection's URI. Those newly created entries will be assigned their own unique edit URI. To modify those entries, the client simply retrieves the resource from the collection, makes its modifications, then puts it back. Removing the entry from the feed is a simple matter of issuing an HTTP DELETE request to the appropriate edit URI. All operations are performed using simple HTTP requests and can usually be performed with nothing more than a simple text editor and a command prompt... In the next installment of this series, I will walk through a number of application scenarios that are considered good uses of the protocol. These include such obvious things as Weblogs, social bookmarking and photo album type applications as well as somewhat non- obvious uses in calendaring, contact management, document and media content repositories, database management, situational applications and even Service Oriented Architecture. Beyond that, you will explore how to implement a Atom Publishing client and server in Java using the Apache Abdera open source Atom implementation currently in incubation at the Apache Software Foundation and will step through the creation of an APP-enabled application service.

  • [September 13, 2006] "Atomic: Atom Protocol Client Implemented as a Firefox Extension." By Alex Milowski. Blog and announcement, September 13, 2006. "I've finally gotten my Atom protocol client as a firefox extension approved by mozilla.org. It can communicate with any number of different Atom protocol servers that support introspection. It starts with introspection and lets you interact with your feeds. It also has some "extensions" for creation of collections (i.e. a POST of a feed element) and modification of feed metadata (i.e., a PUT of a feed element). This client has been tested against the Atom protocol implementation in the eXist XML Database at http://www.exist-db.org. I'd love to know how it works with other protocol implementations. To do anything useful, you need to have access to an Atom Protocol server. That may be the hardest one, as the protocol is still a draft RFC. You can setup your own Atom protocol server using the eXist XML database..."

  • [August 31, 2006] "Atom Tool: The Ape." By Tim Bray. From Ongoing Blog (August 31, 2006). "I've put up an Atom Protocol Exerciser at http://www.tbray.org/ape which might evolve to become a sanity-checking tool something along the lines of the Feed Validator. I don't want to call it a 'validator' because a feed can be said unambiguously to be valid, or not; but a publishing- system interface might be unusably buggy or slow or have moronic authentication policies. All the Exerciser (let's just say 'the Ape' for short) does is perform a bunch of operations that a typical APP client might, and report the results. Also I've taken liberties in reporting some things that aren't covered by the spec that implementors might want to know about. One of the most useful things the Ape does is provide a complete trace of exactly what the client and server sent back and forth to each other; immensely helpful as a debugging aid. Quite a few interesting war stories have been coming out of the Ape-building process. I'll keep this post updated with the current Ape status. The Ape has one required argument, the service document URI. Optionally, you can provide a username/password pair (Basic and Basic+TLS work at the moment) and the names of collections you want Ape to use for posting new entries and media files..."

  • [August 28, 2006] "Apache Abdera: An Open Source Atom Implementation." By James Snell. Apache Incubator Posting. August 28, 2006. "The Apache Abdera developer community has announced its first developer preview release (version 0.1.0-incubating), with binary and source distributions for Java 1.5 and Java 1.4.2. The goal of the Apache Abdera project is to build a functionally-complete, high-performance implementation of the IETF Atom Syndication Format (RFC 4287) and Atom Publishing Protocol (in-progress) specifications. Abdera is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the Apache Incubator PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. The release supports: (1) Parsing Atom Syndication Format 1.0 Feeds; (2) Serializing Atom Syndication Format 1.0 Feeds; (3) Extensions; (4) XML Digital Signature and XML Encryption; (5) A high performance incremental parsing model; (6) Feed Object Model API..."

  • [August 23, 2006] "Google Opens Up Its Base." By Sean Michael Kerner. From Internetnews.com (August 23, 2006). ['GData is a new protocol based on Atom 1.0 and RSS 2.0.'] "The key to any successful Web 2.0 deployment is the availability of an open API. It's a key that Google is now giving out for its base — Google Base that is. The Google Base Data API is now freely available from Google, allowing third party developers to have applications that can interact with Google Base... Underlying the newly available Google Base Data API is Google's GData API, which, according to Google's definition, provides a simple standard protocol for reading and writing data on the web. GData combines both Atom 1.0 and RSS 2.0 XML syndication formats in addition to a few extensions for dealing with queries. 'To acquire information from a service that supports GData, you send an HTTP GET request; the service returns results as an Atom or RSS feed,' Google's documentation states. 'You can update data (where supported by a particular GData service) by sending an HTTP PUT request, an approach based on the Atom Publishing Protocol."

  • [July 19, 2006] "Implementing the Atom Publishing Protocol." By Joe Gregorio. From XML.com (July 19, 2006). "The Atom Publishing Protocol (APP) is nearing completion, many of the design issues have settled down, and there is work being done on implementations and interoperability. Although the interoperability work will go on for years to come, we can put together an implementation and discuss the requirements the APP puts on you, the gotchas, and the ways we can optimize the service. If you've been following along with Restful Web columns at home, you won't be surprised that the implementation is in Python. The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources using HTTP and XML 1.0. The protocol supports the creation of arbitrary web resources and provides facilities for: (1) Collections: Sets of resources, which may be retrieved in whole or in part; (2) Introspection: Discovering and describing collections; (3) Editing: Creating, updating and deleting resources. The Atom Protocol uses the following HTTP methods: GET is used to retrieve a representation of a resource or perform a query; POST is used to create a new, dynamically- named resource; PUT is used to update a known resource; DELETE is used to remove a resource. Along with operations on resources, the Atom Protocol provides list-based structures, called Collections, for managing and organising resources, called Members. Collections contain the IRIs of, and metadata about, their Member resources. For authoring and editing of resources to commence, an Atom Protocol client can examine Introspection Documents which represent server-defined groups of Collections. This initial article in a series dives into some code, implementing draft -08 of the Atom Publishing Protocol. Future articles in the series will build more complex services on top of this APP implementation..."

  • [June 22, 2006] "Atom Feed Thread Extension Approved as a Proposed Standard." James Snell. Blog entry. James Snell, a member of IBM's WebAhead development lab, reported that the Internet Engineering Steering Group (IESG) has approved the "Atom Threading Extension" specification as a Proposed Standard. It's now in the RFC Editor queue awaiting final edits and its very own RFC number. The "Atom Threading Extensions" document describes a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format (RFC 4287). The specification defines an 'in-reply-to' extension element, used to indicate that an entry is a response to another resource. The element MUST contain a "ref" attribute identifying the resource that is being responded to. The element is not unlike the references and in-reply-to email message headers defined by RFC 2822. However, unlike the in-reply-to header, the "in-reply-to" element is required to identify the unique identifier of only a single parent resource. If the entry is a response to multiple resources, additional "in-reply-to" elements MAY be used. A new 'replies' link relation is also defined: an Atom link element with a rel attribute value of "replies" may be used to reference a resource where responses to an entry may be found. If the type attribute of the atom:link is omitted, its value is assumed to be "application/atom+xml". A "replies" link appearing as a child of the Atom feed or source element indicates that the referenced resource likely contains responses to any of that feed's entries...

  • [ June 9, 2006 ] "Tim Bray: The Garibaldi of RSS." By Andy Patrizio. From InternetNews.com ( June 9, 2006 ). "Today, RSS 2.0 and Atom are both in use by RSS readers and sites offering syndication. "RSS 2.0 works fine, but everybody has agreed it should be stable and frozen and never changed again," said [Tim] Bray. "Everybody has agreed if there's further work to be done it should be done under a new name and a new project, and that's what Atom is." Atom "crystallizes what we've learned with RSS and unifies everything in one format, and secondly gives us a publishing protocol to empower anything to become a publishing engine and get more people online," said Bray. Dealing with the RSS/Atom feed protocol is only half the battle. Bray said that an even bigger headache is publishing. All of the popular blogging sites, such as Blogger, TypePad, and LiveJournal, just to name a few, use a different protocol and they aren't interoperable. Bray praised Microsoft's move to put one-click blog publishing in Word 2007, which will come with Office 2007 early next year. But the real killer app for blog publishing, he said, will be camera phones. People want to be able to take a photo with their camera phone and publish it to their blog with one click, he said, and the camera phone operators won't tolerate multiple protocols. "You know they won't be implementing LiveJournal and TypePad and Blogger in millions of cell phones. They're going to pick one protocol. The choice facing LiveJournal and the like will be easy. Do you want all the people with cell phones to access [your site]? Then adopt Atom and you're done," said Bray. At the moment, the IETF is close to finishing the Atom protocol and will begin interoperability testing. After that will come the Atom publishing protocol. Bray expects this to be done by the end of the year. Then comes the really hard part: getting application vendors and middleware vendors in particular to adopt it..."

  • [May 23, 2006] "XML Matters: Up and Atom." By Dethe Elza (delza@livingcode.org, Technical Architect, Justsystems) and David Mertz (mertz@gnosis.cx, Gnosis Software, Inc). From IBM developerWorks. "Atom is really two different things, both related to syndication (blogs, newsfeeds, and other information which gets updated periodically). The Atom Syndication Format is an IETF standard for publishing entries (single topics or items) and feeds (collections of topics or items). The Atom Publication Protocol (sometimes called the Atom API or abbreviated APP) is a means for finding, listing, adding, editing, and removing content from an Atom repository. While Atom the Syndication Format has gone through the IETF process to become a standard, the standards committee is still at work on Atom the Publishing Protocol, although it seems likely that much of it has stabilized at this point. Work is still progressing on the Atom Publication Protocol, and other halo-effect specifications such as Google's Calendar extensions. Sites are adopting Atom rapidly, and both applications and programming tools are adapting to Atom as well. With its open format, extensibility, and clear definition, Atom could be as potent a force for the Web as the relational database was for the enterprise. HTTP GET and View Source are still as potent a combination now as they were in the heady early days of the Web..."

  • [December 07, 2005] "Handling Atom Text and Content Constructs." By Uche Ogbuji. From XML.com (December 07, 2005). "The Atom Syndication Format (RFC 4287) came about in part for social reasons and in part for technical reasons. The social reasons came down to difficulties reconciling factions of existing web feed formats. One of the key technical reasons is that existing web feed formats were not clear and rigorous in specifying rules for and interpretation of embedded content and human-readable text. Atom fixes this deficiency, making things easier for those writing processing code, but it also means you should clearly understand the rules governing such constructs, and, ideally, adopt reusable libraries for the purpose. In this article the author discusses the forms of text and content constructs available in Atom, and in recognized extensions, and how to process them. For the XHTML text construct, one must wrap the content in an XHTML div [perhaps making markup] verbose, but it more than makes up for these shortcomings by offering a very clean layering of XML vocabularies, both of which you can be sure are not tag soup. The overhead is likely to be less imposing if you use XHTML text constructs with the typically longer content in summary. Also, if you prefer, you can declare the XHTML namespace once, on the Atom feed element, and then use the appropriate prefix (or default namespace) for all the XHTML. Atom content also allows arbitrary XML content, as long as you provide an XML media type in the type attribute, with "XML media type" as defined in RFC 3023; thus, you can embed an SVG image in Atom content. If you want to have content in-line while using any non-text and non-XML type, you must include it as Base64 encoded form..."

  • [December 07, 2005] "Catching Up with the Atom Publishing Protocol." By Joe Gregorio. From XML.com (December 07, 2005). "The Atom Syndication Format is now also known as RFC 4287. Atom is an internet standard in the same way that little things like SMTP and HTTP (also known as 'email' and 'the Web,' respectively) are internet standards. Progress on the Atom Publishing Protocol (APP) has lagged a bit, in part because it relies so heavily on the format specification. Now that the format is done, work has progressed rapidly on the protocol. The basic editing model hasn't changed [in recent drafts]: we use the four basic methods of HTTP (GET, PUT, POST, and DELETE) to shuffle Atom Entries around. One of the big differences [in the current model] from gregorio-09 is the absence of SOAP. A SOAP binding may appear some day, but it was considered too much to have that in the core protocol. There were also some proposals to use WebDAV. While those proposals were not accepted, they did have some influence and the WG adopted the term collection from the WebDAV spec. While the APP is not based on WebDAV, there seems to be general agreement that we should peacefully coexist and that a WebDAV collection can also be an APP collection..."

  • [October 31, 2005] "Atom 1.0 Extensions, Part 2: Copyright licenses, automated processing of links, and syndicating threads. An overview of proposed extensions to the Atom 1.0 Syndication Format." By James Snell (Software Engineer, IBM). IBM developerWorks (October 31, 2005). It has become a common practice in the world of syndication to associate copyright licenses with content; the most popular use case being the association of Creative Commons licenses. To facilitate the association of such licenses with Atom 1.0 feeds and elements, an IETF Internet Draft entitled "Feed License Link Relation" proposes a new Atom link relation extension. This mechanism leverages Atom's expressive and extensible link element. By associating copyright licenses with a feed or entry, feed publishers can control how their content is distributed, reused, modified, displayed, and so on. Additional controls are necessary to specify how to process that content. For example, podcast feeds distribute audio content by associating the URL of the audio content with an RSS item using an enclosure element. Most applications that are designed to read podcast feeds automatically download such audio files whenever they access and process a podcast feed. Such automated downloading can cause significant strain on a server that's hosting the content and eat away at the host's bandwidth. To give content publishers the ability to specify their preference that user agents not attempt to automatically download links associated with an Atom feed or entry, an extension has been proposed as an IETF Internet Draft entitled "Atom Link No Follow"; it introduces new attributes that you can specify for the atom:link and atom:content elements in order to control what forms of automated processing feed readers should perform..

  • [October 25, 2005] "Atom 1.0 extensions, Part 1: Feed history, ordering entries, and expiration timestamps." By James Snell (Software Engineer, IBM). IBM developerWorks (October 25, 2005). This is the first of two articles which discusses proposed extensions to the Atom 1.0 Syndication Format. These extensions enable the reconstruction of feed history, the ability to order entries within a feed according to numeric rankings, and the expression of expiration timestamps for syndicated content. A "Feed History" I-D proposes a model that allows feed readers to reconstruct the history of a feed by paging through multiple incremental feed documents. When a feed reader accesses a feed document that has been flagged as being incremental in nature, the reader can see that the content of the feed contains only a partial representation of the feeds' contents. A new Feed Rank extension has been proposed which introduces numeric ranking values into the entries of a feed. Each numeric ranking value is associated with a logical ranking domain that's bound to a ranking scheme. The ranking domain provides a means of composing the set of entries that are to be ranked relative to one another. The I-D entitled "Atom Metadata Expiration: Specifying Expiration Timestamps for Atom Feed and Entry metadata" proposes two new extension elements that you can use to indicate either an exact time or a maximum age after which the metadata contained by the feed or entry expires. In the second part of this series, Snell will examine three more extensions that one can use to: (1) Associate copyright licenses with feeds and entries; (2) Control automated processing of links; (3) Syndicate threaded discussions.

  • [October 29, 2005] "What Is Atom? An Introduction to the Atom Syndication Format." By Ben Hammersley. From XML.com (October 26, 2005). "The Atom Syndication Format is the next generation of XML-based file formats, designed to allow information — the contents of web pages, for example — to be syndicated between applications. Like RSS before it, Atom places the content and metadata of an internet resource into a machine-parsable format, perfect for displaying, filtering, remixing, and archiving. The collection of formats that started it all, RSS, has reached out of the tech world and into the mainstream; its growth has been remarkable. But as a technology grows, its shortcomings become more apparent. What are the differences between Atom and RSS? Apart from the process used to build the specification, and the rigor of the documentation, there are two main substantive changes. These are the Preservation of Metadata, and the concept of Constructs. An Atom feed is made up of standardized elements. Each of these elements is blessed with content that has been organized into one of the options provided by the Reusable Syntax of Constructs. Constructs allow new elements, within new namespaces, to be added to an Atom feed in a controlled way. Elements pointing to a person, for example, should use the Person construct, and not reinvent the wheel. Atom Syndication Format is only the first part of the Atom project, balanced by the Atom Publishing Protocol, more commonly known as the Atom API. The aim of this project is to improve on, and replace, the existing XML-RPC-based publishing protocols such as the Blogger API.

  • [October 07, 2005] "Advertise Web Services with Atom 1.0." By James Snell (Software Engineer, IBM). From IBM developerWorks (October 07, 2005). "Originally published in November of 2001, the draft Web Services Inspection Language was billed as an XML format for assisting in the inspection of a site for available Web services. The fundamental intent of the specification was to provide a simple means of discovering when new services had been made available at a particular endpoint location. Unfortunately, while a few implementations of the specification did emerge in a few products, use of WS-Inspection never really took off. Neither the WS-Addressing specifications nor the related WS-* specifications being developed under the auspices of the W3C and OASIS organizations address the fundamental problem of providing a simple means of notifying clients when new Web services have become available. Enter Atom 1.0. Over the course of the past year, the IETF Atom Publishing Format and Protocol Working Group has been working to define a standard XML format designed, in part, to allow clients to receive notification of when Web-based resources have been created or modified. Originally targeted at the syndication of Weblog and news content, the Atom Syndication Format is capable of serving as a means for distributing any arbitrary data format. In this article the author introduces and demonstrates the combined use of the Atom 1.0 and Web Services Addressing 1.0 specifications as a functional replacement for the now defunct WS-Inspection. A basic understanding of both the Atom and WS-Addressing specifications is assumed and it is recommended that the reader have a copy of both specifications handy as a reference."

  • [September 21, 2005] "Dreaming of an Atom Store: A Database for the Web." By Joe Gregorio. From XML.com (September 21, 2005). "What kind of data store makes sense on the Atom Web? After a year of work — two if you count the work done before the AtomPub WG was formed — the Atom Publishing Protocol (APP) is moving closer to being done. [Though some parts are still] unspecified, and other parts of the protocol are under debate ... some of the protocol is very stable, unchanged from even the earliest drafts. Despite the incomplete nature of the APP, there are plenty of people that are excited about it and are beginning to imagine all sorts of uses for it beyond a weblog publishing API, which was its original target. Over the course of the last couple months several of those ideas have collided often enough that we're starting to see a stable fusion. The ideas that are colliding are the APP and Amazon's OpenSearch... The Atom Publishing Protocol leverages the work done on the Atom Syndication Format and the basics of HTTP to form a simple, yet powerful, publishing protocol. One of the things that doesn't get noticed at first about the Atom Syndication Format is that not only are feeds first class documents, but so are entries... The Atom Publishing Protocol is all about pushing around Atom Entries... One of Amazon's A9 technologies is OpenSearch, a [Creative Commons] CC-licensed specification for search using Atom and RSS; OpenSearch defines a RESTful web service for searching, including a format for advertising what kind of search your site supports, and specifying how to return your search results in Atom or RSS... Imagine enhancing the APP method of editing your weblog with OpenSearch. You could search across all your entries and find the right ones you want to edit or delete. Imagine that you just have a huge glob of storage that you can store Atom Entries in, and which you can edit using the APP, and then search over using OpenSearch. That idea, that big blob of Atom Entries, all editable and searchable, is an Atom Store..."

  • [August 02, 2005] "An Overview of the Atom 1.0 Syndication Format. How this Popular Web Content Syndication Format Stacks Up." By James Snell (Software Engineer, IBM). From IBM developerWorks (August 02, 2005). "This article discusses Atom's technical strengths relative to other syndication formats, and offers several compelling use case examples that illustrate those strengths. Web content syndication is an area of growing importance on the Internet and behind the firewall. What was once the sole domain of bloggers and online news sites is evolving into a platform for next generation Web-based services and content distribution. While the adoption of syndication technologies is growing at a fevered pitch, these technologies have a long history of technical issues, ambiguities, and interoperability challenges that have made life difficult for software developers and consumers who use these emerging trends. To address these issues, members of the syndication technology community came together to pool their combined experiences and define the Atom Syndication Format and the Atom Publishing Protocol standards. On July 15th, 2005, the first of these specifications, the Atom Syndication Format, was released to the world for implementation. It is important to point out that it is not the intent of this discussion to disparage RSS in any way. Rather, the goal is to illustrate the types of improvements that the Atom format delivers relative to the existing family of syndication formats, and to highlight the strengths inherent in the Atom format... In a [May 2004] introduction, Uche Ogbuji wrote that one of the goals of Atom 'was to create a more technologically sound design than many of the flavors of RSS, using the practical experience of the many RSS users to make the practical design compromises that would enable the new format to work in harmony with the architecture as well as the culture of the Web.' While it has taken some time, a lot of careful discussion, and a significant amount of effort on the part of IETF working group participants, Atom 1.0 now achieves the goals of providing a simple, well-defined, and unambiguous format for content syndication on the Web..."

  • [August 01, 2005] "Atom Syndication Format: Introduction." By Sam Ruby [email: rubys@intertwingly.net]. August 01, 2005 or later. "This document focuses on The Atom Syndication Format produced by the IETF AtomPub Working Group. Atom is the name of an XML-based Web content and metadata syndication format, and an application-level protocol for publishing and editing Web resources belonging to periodically updated websites. All Atom feeds must be well-formed XML documents, and are identified with the 'application/atom+xml' media type. At the top level of an Atom syndication feed is [the] feed element. General considerations: (1) All elements described in this document must be in the "http://www.w3.org/2005/Atom" namespace; (2) All timestamps in Atom must conform to RFC 3339; (3) Unless otherwise specified, all values must be plain text, i.e., no entity-encoded HTML; (4) the xml:lang attribute may be used to identify the language of any human readable text; (5) the xml:base attribute may be used to control how relative URIs are resolved. Extending Atom: The atom content document is designed to support the direct inclusion of other XML vocabularies. Any fully qualified URI may be used a value for the rel attribute of link elements. Elements from other namespaces may be included pretty much anywhere. This means that most RSS 1.0 and RSS 2.0 modules may be used in Atom..."

  • [July 15, 2005]   IETF Atom Syndication Format Specification Declared Ready for Implementation.    With the July 14, 2005 release of the The Atom Syndication Format Version -10 specification by the IETF, the Atom Format Internet Draft has been declared an appropriate basis for implementation of Atom 1.0. Atom is an XML-based Web content and metadata syndication format. Atom will live alongside RSS Version 2.0, and is expected by many to gradually replace RSS ("RDF Site Summary" or "Really Simple Syndication). The The Atom Syndication Format has been produced by members of the IETF Atom Publishing Format and Protocol (atompub) Working Group under the direction of WG Co-Chairs Tim Bray and Paul Hoffman. The version -10 Internet Draft fixes a few things from the -09 draft sent to the IESG for final review. Eleven Internet drafts have been produced by the WG, beginning with Version -00 dated July 8, 2004. The IETF's specification for the Atom 1.0 data format is described as "cooked and ready to serve." According to an announcement from Tim Bray, "The Atom 1.0 spec still has one registered objection from a member of the IESG, but the WG agreed that the objection was reasonable and we think the latest draft linked above fixes it; assuming he agrees, Atom very soon becomes an IETF standard. It will eventually get an RFC number, but that may take a while, first because the RFC Editor machinery works slowly, and secondly because we have a normative reference to Ned Freed's re-work of the MIME-type RFCs, which isn't quite finished yet. Atom is "an XML-based document format that describes lists of related information known as feeds. Feeds are composed of a number of items, known as entries, each with an extensible set of attached metadata. For example, each entry has a title. The primary use case that Atom addresses is the syndication of Web content such as Weblogs and news headlines to Web sites as well as directly to user agents. However, nothing precludes it from being used for other purposes and types of content."

  • [July 15, 2005] "Atom: The Standard in Syndication." By Robert Sayre. From IEEE Internet Computing Volume 9, Number 2 (July/August 2005), pages 71-78. Online via IEEE Distributed Systems Online. Sayre's article provides extensive discussion on the "History of Syndication Interoperability," "The First RSS," and "RSS Versions" — as well as surveying the specifications produced by the IETF Working Group. "Early syndication and publishing protocols faced various problems related to interoperability, scalability, and extensibility. The Atom format and protocol builds on earlier efforts to establish an open, extensible, interoperable, and clearly specified framework for Web-logging applications. Atom has already been deployed on a wide variety of platforms. By closely examining previous syndication formats and protocols, the Atompub working group has been able to 'pave the footpaths,' and design a standard built around well-known and proven usage patterns... Maintaining interoperability is vital to preserving the [blogging] medium's effectiveness and openness. It is also challenging because the environment values and encourages contributions from everyone... Many computing standards are hammered out by agreement between a comparatively small number of technology professionals and companies, for use almost solely by technically trained implementors. In contrast, the syndication community has always encouraged 'folk coding,' so the variety and number of implementations is immense and growing. This empowers people to innovate rather than make feature requests, but accommodating this inclusive, anything-goes ethos while delivering a predictable, consistent experience for nontechnical users is a constant struggle. Atom is an IETF effort to improve syndication interoperability while maintaining an approachable design. By addressing failings in previous formats and protocols, the products of the -Atompub working group provide a well-specified and easily understood infrastructure for the future of syndication and publishing on the Web..." [Note: In the section "RSS Versions" the author says "A conservative count shows eight document formats calling themselves RSS. In order of appearance, they are 0.90, 0.91, 1.0, 0.92, 0.93, 0.94, 2.0, and 1.1. The versions in widest deployment today [2005-07] are 0.91, 1.0, and, most popularly, 2.0..."]

  • [July 14, 2005] "RSS 2.0 and Atom 1.0, Compared." By Tim Bray, Paul Hoffman, Sam Ruby, and Rob Sayre. Pre-Wiki Snapshot. July 14, 2005 [or later]. This document is a snapshot of the live versio on the Atom wiki. "People who generate syndication feeds have a choice of feed formats. As of mid-2005, the two most likely candidates will be RSS 2.0 and Atom 1.0. The purpose of this document is to summarize, as clearly and simply as possible, the differences between the RSS 2.0 and Atom 1.0 syndication languages. The RSS 2.0 specification is copyrighted by Harvard University and is frozen. No significant changes can be made and it is intended that future work be done under a different name; Atom is one example of such work. The Atom 1.0 specification, in the course of becoming an IETF standards-track RFC, represents the consensus of the Atompub Working Group within the IETF, as reviewed and approved by the IETF community and the Internet Engineering Steering Group. The specification is structured in such a way that the IETF could conceivably issue further versions or revisions of this specification without breaking existing deployments, although there is no commitment, nor currently expressed interest, in doing so. [In terms of] extensibility, RSS 2.0 is not in an XML namespace but may contain elements from other XML namespaces. Atom 1.0 is in an XML namespace and may contain elements or attributes from other XML namespaces. There are specific guidelines on how to interpret extension elements. Additionally, there will be an IANA managed directory of extensions where anybody can register their namespaces. Finally, Atom 1.0 provides recommended extension points and guidance on how to interpret simple extensions..."

  • [June 24, 2005] "Microsoft Draws Cheers, Jeers over RSS in Longhorn." By Matt Hicks. From eWEEK (June 24, 2005). "Microsoft's vision for tying RSS directly into the next release of Windows drew cheers and jeers among the syndication-feed enthusiasts gathered here Friday. It drew accolades for its potential to smooth some of the user kinks in discovering and managing feed subscriptions, while it awakened fears that the Redmond, Wash., software maker is attempting to embrace the still-emerging market for syndication feeds in order to dictate its direction. The core of Microsoft's RSS plans is to bring feeds into Windows applications, both its own and those from developers. Longhorn will provide a common feed list of subscriptions and a common feed store of data in Longhorn, which will be available to applications through Windows APIs, said Dean Hachamovitch, Microsoft's general manager of Longhorn browsing and RSS technologies... Another part of Microsoft's RSS plans seemed to draw the most criticism. Microsoft also released a specification for an extension to one format of syndication feeds, RSS 2.0, for handling ordered lists. Microsoft is offering the list specification under a Creative Commons license. During a demonstration, Microsoft showed how lists such as Amazon.com Inc.'s wish lists could be brought into a Windows application through the RSS extensions. The idea of extending RSS to other applications may be attractive to some, but Microsoft's approach drew criticism from Bob Wyman, co-founder and chief technology officer of PubSub Concepts Inc., a startup service that aggregates RSS feeds. He criticized Microsoft for focusing on a specific format, RSS 2.0, and for not bringing the extension before an open standards body such as the Internet Engineering Task Force. An alternative syndication format, Atom, is weaving its way through the IETF standards process. 'They're ignoring the IETF Atom standard and locking down to the legacy RSS 2.0 standard,' Wyman said. 'To try to use Creative Commons as an indication that you're somehow open is a tremendous amount of spin.' PointerClick here to read more about Atom's effort to become an IETF standard. For retrieving feeds from the Web, Microsoft is including support for Atom and other major syndication-feed formats other than RSS 2.0, officials said. Others see little difference between how Microsoft is extending RSS and how the RSS 2.0 specification emerged. [Marc] Strolhein likened Microsoft's RSS extension to the role Dave Winer played as the major developer behind RSS 2.0..." See "Microsoft Bakes RSS into Longhorn," by Peter Galli (eWEEK, June 24, 2005).

  • [May 24, 2005] "RSS and Atom: A Quick Overview." By Bob Wyman (PubSub). Presented at the News Standards Summit 2005, Amsterdam RAI Centre, Netherlands. The presentation supplies a short 'RSS/Atom History' and example instances of RSS 2.0 and Atom feeds/entries. From slides 8-10, 'Atom Enhancements to RSS': Clarity in the specification: Carefully worded, with every word fought over at length on IETF mailing lists; RNG [RELAX NG] specifications provided to reduce ambiguity; Thoroughly specified, less ambiguous; Designed with Matching API; Well-defined Content Model; Support for content types; Support for linked, rather than embedded, content; Broader range of solutions addressed; Defined method for encryption and digital signatures; Defined Extensibility Model; Mandatory globally unique Entry IDs; Mandatory timestamps; Distinction between Summary and Content; Distinction between author and contributor; Free Standing Atom Entry Documents (supports API and 'Atom over XMPP'); Atom:source elements preserve attribution on copy; atom:updated to flag 'significant' changes; Multiple 'enclosures' via link element; Relative URI support via xml:base; Support for xml:lang; I18N support enhanced by use of IRIs; Support for RFC3339 dates (ISO-like dates). [cache

  • [April 20, 2005]   IESG Issues Last Call Review for Atom Syndication Format as a Proposed Standard.    The Internet Engineering Steering Group (IESG) has announced a last call review of The Atom Syndication Format IETF Internet Draft. A request has been received to approve the Atom Syndication draft as a Proposed Standard, and the IESG plans to make a decision in the next few weeks. Review comments should be submitted to the designated IESG or IETF mailing lists by May 04, 2005. The Atom Syndication Format specification has been produced by members of the IETF Atom Publishing Format and Protocol (atompub) Working Group. It defines Atom as an XML-based Web content and metadata syndication format. Atom is expected to be serve as the successor to the popular RSS ("RDF Site Summary" or "Really Simple Syndication") news format, and in many contexts, references to RSS are intended to mean "RSS or Atom." Many applications already process newsfeeds in Atom or any of the several variant RSS XML formats. Atom is an XML-based document format that "describes lists of related information known as feeds. Feeds are composed of a number of items, known as entries, each with an extensible set of attached metadata. For example, each entry has a title. The primary use case that Atom addresses is the syndication of Web content such as Weblogs and news headlines to Web sites as well as directly to user agents." The two kinds of Atom Documents defined in the specification (Atom Feed Documents and Atom Entry Documents) must be well-formed XML, and are identified using the 'application/atom+xml' media type. Atom uses XML Namespaces to uniquely identify XML element names, and terminology from the XML Infoset. The specification does not define a DTD for Atom Documents, but expresses conformance within the prose; it provides a RELAX NG Compact Schema in an Informative Appendix B. The specification also places some requirements on Atom Processors. Any element defined in The Atom Syndication Format specification may have an xml:base and/or xml:lang attribute. The value of the xml:lang attribute "indicates the natural language for the element and its children [and] the language context is only significant for [particular] elements and attributes declared to be 'language-sensitive'," as defined in the specification.

  • [February 06, 2005] relLicense. By Tantek Çelik (Technorati, Inc). Draft Specification 2005-02-06. This specification is copyright (c) 2004-2005 by the authors. However, the authors intend to submit this specification to a standards body with a liberal copyright/licensing policy such as the GMPG, IETF, and/or W3C. A "simple, open, format for indicating content licenses which is embedable in (X)HTML, Atom, RSS, and arbitrary XML. relLicense is one of several microformat open standards... RelLicense is one of several MicroFormats. By adding rel="license" to a hyperlink, a page indicates that the destination of that hyperlink is license for the current page. Multiple such rel="license" hyperlinks indicate that the page is available under any of the referred licenses. For example (see) two hyperlinks could be used to declare that a page is available under either a Creative Commons 2.0 Attribution Required license or the Apache 2.0 license..." See Microformats.

  • [January 18, 2005]   Independent Developers Release Draft Version of RSS 1.1 (RDF Site Summary).    A group of RSS 1.0 users has announced the release of RSS 1.1: RDF Site Summary as a content syndication format intended to update and replace the popular RSS Version 1.0. RSS stands for "RDF Site Summary," "Rich Site Summary," "Really Simple Syndication," and perhaps similar phrases . It has become a popular XML format for news syndication since its creation in 1997. The two major variants of RSS include an XML RDF-based specification (RSS version 0.9, 1.0, draft 1.1) and a non-RDF XML specification (RSS versions 0.91, 0.92, 0.93, 0.94, 2.0). Both the draft RSS 1.1: RDF Site Summary and the non-RDF RSS 2.0 Specification are published under a Creative Commons License. RSS Version 1.1 is the independent project of three RSS 1.0 users, Sean B. Palmer, Christopher Schmidt, and Cody Woodard. These developers, "tired of the deficiencies of [the RSS Version 1.0] format, decided to create a more architecturally solid format based upon it. RSS 1.1 has not yet been officially ratified by any group, but has been intially well received by selected members of the RSS community, and a furtherance of the initial tools and implementations should be expected." According to the specification abstract, RSS 1.1 "is an application of the W3C's RDF and XML languages. It has better internationalization support, utilizes more up-to-date facilities of its constituent languages than RSS 1.0, and fixes a number of other issues with the RSS 1.0 specification. RSS 1.1 is as extensible as RSS 1.0 and can even make use of its extension modules." The RSS Version 1.1 specification is said to be "designed for current RSS 1.0 users, and is not designed to compete with the currently-under-development Atom specification. It is created taking into account a number of the problems brought up since the creation of the RSS 1.0 specification, and aims to correct these issues while maintaining a relatively high level of backwards compatibility for increased tool support."

  • [December 16, 2004] "The Atom Notification Protocol." By James M Snell [WWW]. IETF Network Working Group. [Individual] Internet Draft. Reference: 'draft-snell-atompub-notification-00'. December 14, 2004, expires June 14, 2005. "This memo presents a protocol for posting notifications of new or updated content using a combination of the Atom Syndication Format and HTTP POSTs. The Atom Notification Protocol has been designed to complement the Atom Publishing Protocol by providing the means of sending notifications when Atom-based content is created or updated. The Atom Notification Protocol works by POSTing Atom Entries or Atom Feeds to a NotificationURI using HTTP POST. As is the case with the Atom Publishing Protocol, this document does not seek to specify the form of the URIs that are used. This document does, however, specify the formats of the entities posted to those URIs. The NotificationURI is used to POST notifications. A notification consists of a single Atom Entry or Atom Feed. The notification is essentially a one-way operation that implies no semantics or action on the part of the receiver. The request contains a filled-in Atom Entry or Atom Feed. A notification request containing an Atom Entry is intended to notify the receiving endpoint that a specific entry has been created or updated. A notification request containing an Atom Feed is intended to notify the receiving endpoint that a specific feed has been created or updated..." [Author's note, posted to 'atom-syntax@imc.org' and 'atom-protocol@imc.org' lists: I have published the first draft of the Atom Notification Protocol... I would like to discuss the possibility of this work being picked up by the working group. It may even be feasible to incorporate this into the main body of the Atom Protocol spec. In the meantime, however, please take a look and review the draft and please comment on the protocol mailing list..."

  • [November 12, 2004] "Atom Syndication Spec Ready for IETF Closeup." By Ryan Naraine. From eWEEK (November 12, 2004). "Work on the new Atom content syndication format is almost done and ready for review by the Internet Engineering Task Force, a key backer announced Friday. Tim Bray, technology director at Sun Microsystems Inc. and primary voice behind The Atom Project, has given the thumbs-up to the draft format and is proposing that the working group submit the specs for IETF ratification without further delay. 'The [format] is already substantially better and cleaner than any other known syndication-format specification that's out there,' Bray wrote on the Project's wiki. 'At this point, the Atompub working group would best serve the community, not by further polishing of this draft, but by giving it over to the IETF for review and implementors for experience and feedback.' The Atom Project's work has led to bitter acrimony in the content syndication space because it is seen as a replacement for the popular RSS (Really Simple Syndication) format championed by Harvard fellow Dave Winer and embraced by some of the biggest technology firms. Winer, who is credited with co-writing the RSS format, has publicly proposed a merger of the two competing standards to create a backwards-compatible format. However, the Atom Project pushed ahead with its work within the IETF, culminating in Bray's latest suggestion. 'What we've done in Atom-land is adopted the bits of RSS that get used and ditched the ones that don't get used,' Bray said, adding that there still are problems with RSS that need addressing. On his Scripting News blog, Winer shot back: '[I] find the benefits of the possibly-final Atom to be vague, and the premise absolutely incorrect.' Winer pointed out that RSS has already been widely deployed, successfully, by users of all levels of technical expertise. He said tech heavyweights such as Apple Computer Inc., Microsoft Corp., Yahoo Inc. and media outlets such as The New York Times, Reuters, The Wall Street Journal and the BBC were already using RSS to shuttle XML-based content to users..."

  • [June 28, 2004] "Apple's RSS Embrace Could Bolster Adoption." By Matt Hicks. In eWEEK (June 28, 2004). "By giving its blessing to XML syndication, Apple is joining the trend of browser makers embracing Web news feeds and potentially bringing the technology to the masses. Apple Computer Inc. CEO Steve Jobs on Monday previewed the company's next version of its Web browser, dubbed Safari RSS. RSS refers to the acronym for Really Simple Syndication, the major format for XML syndication. Apple's Web browser is neither the first nor the only one to support syndication feeds. Opera Software ASA introduced RSS support with its latest browser, Opera 7.50, released in May, and the Mozilla Foundation is planning a feature to bookmark feeds with its Firefox 1.0 release later this year. Safari RSS is scheduled to be available with Apple's next Mac OS X release, code-named Tiger, planned for the first half of 2005... Microsoft's Internet Explorer, with 94 percent market share, has no support for reading or aggregating RSS feeds, and company officials declined to discuss whether it is planning any future support. But the Redmond, Wash., company previously has indicated that Longhorn will include RSS aggregation. 'Ultimately, what matters is what Microsoft does with Internet Explorer,' said Dave Winer, the co-author of RSS, who expect Microsoft to eventually include RSS support in a range of products... Cupertino, Calif.-based Apple is using RSS as a blanket term for both various versions of the RSS format as well as the rival format, Atom, all of which it plans to support. Opera also is supporting various versions of RSS from 0.90 and higher, according to its Web site. Mozilla plans to support multiple versions of RSS and Atom... The browser makers are all taking various approaches to incorporating feeds into the browser. Opera, of Oslo, Norway, has added RSS support within its mail application, handling feeds like e-mail messages. The browser also can detect pages with feeds, and users can click a site's XML icon to automatically subscribe. Mozilla, based in Mountain View, Calif., plans to include its news feed support with the beta release of Firefox 1.0 in about six weeks, Goodger said. The new feature will let users save and organize feeds within the browser's bookmarks, which will display an updated list of feed items. Firefox also will display an icon or prompt to indicate that a Web page has an available feed, Goodger said..."

  • [June 16, 2004] "IETF Forms New Atom Publishing Format and Protocol (atompub) Working Group." The Internet Engineering Steering Group (IESG) has announced the formation of an Atom Working Group in the IETF Applications Area. Atom is being created as an enhancement to functionality provided in the popular RSS syndication format, currently documented in several semi-official XML specifications. Atom "defines a feed format for representing and a protocol for editing Web resources such as Weblogs, online journals, Wikis, and similar content. The feed format enables syndication; that is, provision of a channel of information by representing multiple resources in a single document. The editing protocol enables agents to interact with resources by nominating a way of using existing Web standards in a pattern. Chaired by Paul Hoffman and Tim Bray under the supervision of Applications Area Advisor Scott Hollenbeck, the IETF Atom Publishing Format and Protocol (atompub) Working Group will "use experience gained with RSS (variably used as a name by itself and as an acronym for 'RDF Site Summary', 'Rich Site Summary', or 'Really Simple Syndication') as the basis for a standards-track document specifying the model, syntax, and feed format. The feed format and HTTP will be used as the basis of work on a standards-track document specifying the editing protocol. The goal for the working group is to produce a single feed format and a single editing protocol; the working group will only consider additional formats or additional protocols if those charter changes are approved by the IESG." According to the new WG Charter, the working group "will also take steps to ensure interoperability, by unambiguously identifying required elements in formats, clearly nominating conformance levels for different types of software, and providing clear extensibility mechanisms and constraints upon them." Atom currently consists of "a conceptual model of a resource, a concrete syntax for this model, a syndication and archiving format (the Atom feed format) using this syntax, and an editing protocol using this syntax. The Atom protocol will be designed to provide security services for updating and accessing dynamic online resources. The working group will consider current known issues with requirements for remote access, along with the fact that many such resources are constrained by providers who provide the resource owners with little configuration control." The proposed WG schedule calls for release of initial Internet Drafts of the Atom feed format and Atom editing protocol in June 2004. These Internet Draft would be submitted approval as Last Call drafts in March 2005, and would be submitted to the IESG for consideration as Proposed Standards in April 2005.

  • [June 16, 2004] Atom Publishing Format and Protocol (atompub) Working Group Formed. IESG announcement June 16, 2004.

  • [June 16, 2004] "The Atom Link Model." By Mark Pilgrim. From XML.com (June 16, 2004). "Atom is an emerging XML vocabulary and protocol for syndication and editing. Atom has a coherent linking model to express a number of different types of links. Atom borrows heavily from the 'link' markup element in HTML, although they are not identical. A central concept of Atom is the concept of the alternate link, sometimes called the 'permanent link' or 'permalink'. Every Atom feed, and every entry within every feed, must have an alternate link that points to the permanent location of that feed or entry. The terminology of calling it an 'alternate' link is borrowed from the HTML 'link' element, the specification of which states that an alternate link 'designates a substitute version for the document in which the link occurs'. At the feed level, the alternate link points to the home page of the site that the feed is syndicating. At the entry level, the alternate link points to the 'permalink' of that entry in some other format — most often HTML, although it can be any content type. This article explores several of the most common link types that are already deployed in Atom feeds today... Comment feeds: Many weblogs, community sites, and general purpose sites allow visitors to post comments on individual articles. This intersects Atom in two related ways. In Atom, a comment is represented like any other entry, and many publishers now generate comment feeds for individual articles. To make these per-article comment feeds easier to find and subscribe to, Atom has a link tag to point to an entry's associated comment feed..."

  • [June 09, 2004] "Google Mulls RSS Support." By Stefanie Olsen and Evan Hansen. In CNET News.com (June 09, 2004). "Google is considering renewing support for the popular RSS Web publishing format in some services. Along with rival Atom, RSS is a leading candidate to form the basis of an industry standard for a new style of Web publishing that lets readers easily compile news headlines on the fly. Were Google to support both RSS and Atom equally, it might help ease growing pains for a swiftly rising movement of Web publishing. It would also restore Google to the status of a neutral party in the midst of a bitter fight between backers of RSS and Atom, who have been divided since last summer when critics of RSS banded together to create the alternative format. Since then, many blog sites and individuals have rallied behind Atom... Google is central to the debate because of its mounting influence in the online community and within Web publishing circles as the owner of Blogger. The Mountain View, Calif.-based company, which is gearing up for a $2.7 billion initial public offering later this year, recently redesigned Blogger with simplified features to help newbie Web surfers publish regular accounts of their lives online, a move to appeal to wider audiences. Google also has plans to introduce a raft of community services, including e-mail discussion groups (Google Groups 2), free Web-based e-mail and search personalization tools, which could eventually tap the syndication format... A slew of feed readers or news aggregators has emerged to take advantage of the technology and spur consumer demand. Newsgator, for example, lets people subscribe to various Web logs and news sites and have the feeds delivered to their e-mail via a plug-in for Microsoft Outlook, at a cost of $29. Topix.net lets people parse news into 150,000 different categories, even down to a ZIP code, and create their own information site. Pluck recently released a set of browser add-ons for Microsoft's Internet Explorer with an RSS reader. Many news readers support both RSS and Atom, although some support only one or the other. Despite the fissure, RSS has been gaining allegiance among many computer makers and online publishers. In recent weeks, Time magazine, Reuters, Variety.com and Smartmoney.com have started supporting the format, syndicating their headlines to news aggregators and individuals..."

  • [May 28, 2004] "Atom Project: W3C Working Group." By Karl Dubost and other W3C Team members. Draft Mockup, Atom Wiki and mailing list. W3C team members have prepared a draft of what could be an Atom Working Group Charter if technical work on the Atom syndication format were to be hosted at W3C. The draft is characterized by W3C's Karl Dubost as "just a mockup and nothing official." Draft mission statement: "The Working Group will be chartered to define Atom, a feed format for representing and a protocol for editing Web resources such as Weblogs, online journals, Wikis, and similar content. The feed format enables syndication; that is, provision of a channel of information by representing multiple resources in a single document. The editing protocol enables agents to interact with resources by nominating a way of using existing Web standards in a pattern." W3C Team members contributing to the draft include Dan Brickley, Karl Dubost, Max Froumentin, and Matt May. See the posting and the letter from Eric Miller.

  • [May 25, 2004] "Thinking XML: Use the Atom format for Syndicating News and More. Originally an RSS replacement, Atom Spins into the Nucleus of the Conversational Web." By Uche Ogbuji (Principal Consultant, Fourthought, Inc). From IBM developerWorks. May 25, 2004. "The Web has always included sites that present series of articles, events, and other postings which are meant to be shared and cross- referenced. With large parts of the Web becoming conversational communities, many in these communities have come together to work on an XML-based standard for such interchange and cross-reference. Atom is the product of this effort — a format and API for exchanging Web metadata. Originally an RSS replacement, Atom is now spinning into the nucleus of the conversational Web. Atom is remarkable for many reasons, but especially in how it has remained simple despite being the product of one of the largest committees that ever assembled itself for a community specification. Atom comprises a Syndication Format Specification, which is the XML format for representing information about a Web resource, and an API Specification, which is a set of conventions based on HTTP for retrieving and modifying information in Web resources. Both specifications are written as Internet Drafts with the goal of standardization as RFCs, although currently only the API spec has been formally submitted to the Internet Engineering Task Force (IETF). In addition to the XML syntax, Atom is also being developed in RDF form using Web Ontology Language (OWL). Several Atom implementations are already available for experimentation and the Atom community is quite open, in case you're inspired to contribute to the effort..."

  • [May 14, 2004] "XML Syndication Supporters Mulling W3C Move." By Matt Hicks. In eWEEK (May 14, 2004). "The effort among Atom supporters to create a standard XML syndication format took a new turn this week as the Web's leading standards body suggested a new route. The World Wide Web Consortium invited the Atom community to form a working group under its auspices, rather than within the Internet Engineering Task Force (IETF). Atom proponents since have been pursuing the formation of a working group in the IETF, a first step toward creating a formal standard. Atom is an alternative syndication format to RSS (Really Simple Syndication), and the rise of dueling formats has created disagreement, and at times acrimony, among their backers. In March, the major proponent of RSS and its co-author, Dave Winer, suggested the merging of Atom and RSS into a common format in a process managing through a major standards body. Popular with blogs, RSS and Atom news feeds increasingly are gaining more mainstream adoption. The feeds deliver XML content that can be read in news readers available as standalone applications and as plug-ins to e-mail clients. Yahoo Inc. earlier this year provided the ability to search and read syndication feeds to its portal, and earlier this week Opera Software ASA included an RSS reader in its newest Web browser. The W3C's Atom suggestion came in a public e-mail on Wednesday from Eric Miller, W3C Semantic Web Activity Lead, sent to the IETF and an Atom mailing list. Miller could not be reached for comment on Friday. "The W3C agrees that Atom is an important developing application," Miller wrote in the e-mail. "We feel that its specific relevance to the Web, however, indicates that it may find more success in a standards setting organization with work in similar areas — We suggest that the Atom community propose to do this work in the W3C'..." See "Atom Project: W3C Working Group."

  • [May 05, 2004] "IESG Announces Proposal for IETF Atom Publishing Format and Protocol Working Group." On May 05, 2004 the Internet Engineering Steering Group (IESG) announced the proposal for a new IETF Atom Publishing Format and Protocol Working Group within the IETF Applications Area.

  • [April 07, 2004] "Normalizing Syndicated Feed Content." By Mark Pilgrim. From XML.com (April 07, 2004). "[Suppose] you want to write a program to read RSS and Atom syndicated feeds. Sounds simple enough. After all, RSS stands for 'Really Simple Syndication' (or 'Rich Site Summary', or 'RDF Site Summary', or something), and Atom is just RSS with different tag names, right? Well, not exactly... Atom was first proposed last summer, and still in active development, it has been implemented by a number of early adopters, including Blogger, Typepad, and LiveJournal. That means there are approximately 3 million Atom feeds in the wild. So it's important enough for you to pay attention to it, and it's not that hard to learn. It has not fractured into multiple incompatible versions, but it's early yet. These things take time... [In this article] I'm going to use XPath throughout this article to describe how to pick out the pieces of data you want from various flavors of syndicated feeds... Feeds generally have titles, and then individual entries within feeds may or may not have their own titles. Entry titles are required in RSS 0.90, Netscape RSS 0.91, Userland RSS 0.91, RSS 1.0, and Atom, although in Atom the entry title may be blank. Also, RSS 2.0 entry titles are required if there is no entry description... [as for] the Atom content model, it's a hybrid model; values can be included in a feed in several ways. The two main things to know are the type and mode attributes. The mode attribute will tell you how the data is encoded, and the type attribute will tell you the content type (once you've decoded the value). That's not as complicated as it sounds..."

  • [February 03, 2004] "Atom API Update." By Joe Gregorio. From O'Reilly Webservices.XML.com (February 03, 2004). "Version 8 of the draft Atom API for weblog authoring has just been released, and contains substantial changes from version 7. In this article the editor of the specification showed how the Atom API can be used to edit the content of a typical weblog. Despite the changes, the API hasn't left its guiding principles behind: a well-defined data model (with schemas and everything), doc-literal style web services (not RPC), taking full advantage of XML, namespaces, HTTP; secure (no passwords in the clear), etc. Two of the big changes have to do with API discovery. Version 7 contained a file called the Introspection file. The Introspection file listed all of the API endpoints supported by the server and the URIs that handled them. Each of the URIs listed in the Introspection file may have different mime-types and allowed HTTP methods. For example, you can only do a GET on the URI in search-entries, and it returns the results in an XML format specific to search results in the Atom API. This has changed dramatically in revision 8: there are only 3 types of URIs and they all work with the Atom format, either as a whole or by using an entry fragment of the Atom feed format. Of course, Atom isn't necessarily restricted to just weblogs..."

  • [December 12, 2003] "Atom in Depth." By Sam Ruby (Intertwingly.Net). Prepared for XML Conference 2003. Sam Ruby (Senior Technical Staff Member in IBM Emerging Technologies Group, also VP, Apache Software Foundation) provided a state-of-affairs overview of the Atom news syndication format at the recent News Standards Summit. The 59 slides from the presentation cover the Background to Atom, Core model, Syndication, description of the 'API', and the Web Accessible Archive. Sam: "The key insights are these: design Atom such that content is not treated as a second class citizen; insist upon a uniform mechanism for expressing the core concepts independent of the usage; keep the format open and simple. Atom is based heavily on the concepts and experiences with RSS. Special thanks go out to: NetScape, UserLand, RSS-Dev working group, and especially the RSS community! On October 22nd, Mark Pilgrim and I announced the availability of a RSS validator built from the ground up to support all versions of RSS. Both in the development effort itself, and in examining both feeds that failed, and feeds that one aggregator developer or another wished would fail, we became frustrated by a number of ambiguities in these specs. Contrary to what some would have you believe, pretty much all of these ambiguities apply to all RSS versions. [As to the Atom 'API':] Instead of focusing on Applications, the focus is on Data (Post, Get, Put, Delete); clients may optionally use SOAP..." See the XML 2003 conference presentation entry: "Atom is an emerging format for creating, syndicating, and archiving of weblog information. This paper explores the design and implementation of this protocol..."

  • [October 22, 2003] "Atom as the New XML-Based Web Publishing and Syndication Format." This news item provides a snapshot description of Atom (Pie/Echo) as of October 2003.

  • [October 15, 2003] "The Atom API." By Mark Pilgrim. From XML.com (October 15, 2003). "Atom is an up-and-coming format for editing, syndicating, and archiving weblogs and other episodic web sites. The final details are still being hashed out. The Atom API was designed with several guiding principles in mind: Well-defined data model, with schemas and everything; doc-literal style web services, not RPC; take full advantage of XML and namespaces; take full advantage of HTTP; secure, so allow no passwords in the clear. The Atom content model can handle more than just XHTML: any MIME type can be expressed (specify it in the @type attribute), and non-XML content (such as HTML or plain text) is simply escaped or put in a CDATA block, with a mode="escaped" attribute on the content element. It can even handle binary content (such as an image), including a base64-encoded representation of the data. So we're back to a document- centric, REST-inspired service again. The Atom API has several other methods beyond add, edit, delete, retrieve, search. It can be used for posting comments on entries, managing users and user preferences, managing categories, managing site templates; eventually it will be usable for everything you can do manually with your weblog through your server's browser-based interface..." See also Sam Ruby's comments at the News Summit.

  • [August 05, 2003] "A Weblog API For the Grassroots." By Rich Salz. From O'Reilly WebServices.xml.com (August 05, 2003). Previously the author looked at the Necho message format and compared it to RSS, its predecessor. "In this column, I want to look at its API. Joe Gregorio is the main author of the API, written in the IETF RFC format. Joe is using Marshall Rose's xml2rfc package, so various formats are available. Make sure to pick up the latest version; as of the time of this writing, draft 6 was the most current one. That API drafts use the name 'Atom', which was the old favorite, but it had trademark conflicts. As you read the first of this column, I'll be talking about the Atom API, which is used to manipulate what I previously called Necho data. But both of those might end up being called Feedster pretty soon, judging by an entry in the Wiki, whose URL still reflect it's original name, pie..."

  • [July 18, 2003] "Debate Flares Over Weblog Standards. Despite Technical Battles, Weblogs Prepare to Alter the Collaboration and Content Management Space." By Cathleen Moore. In InfoWorld (July 18, 2003). "Weblogs are poised to roil the status quo of enterprise collaboration and content management despite recent debate regarding the protocols underpinning the technology. Most Weblogs are currently fueled by RSS, known both as Really Simple Syndication and RDF (Resource Description Framework) Site Summary. Based on XML, RSS is a Web publishing format for syndicating content; it is heralded for its simple yet highly effective means of distributing information online. Although not officially sanctioned by a standards body, the format enjoys wide adoption by RSS content aggregators and publishing systems. Despite the undisputed popularity and proven utility of RSS, a new standard is emerging in an attempt to lay the foundations for the Weblog's future. Originally dubbed Echo and now rechristened as Atom, the effort is described as a grassroots, vendor-neutral push to address some of the limitations of RSS... Plans are to submit Echo/Atom to a formal standards body, most likely the Internet Engineering Task Force (IETF), according to Sam Ruby, a member of IBM's Emerging Technologies Group and one of the developers of Echo/Atom. Six Apart plans to release Echo/Atom test interfaces in the next shipping versions of its Movable Type Weblog product and in its TypePad-hosted Weblog service, due this summer..."

  • [July 08, 2003] "Vox Populi: Web Services From the Grassroots." By Rich Salz. From O'Reilly WebServices.xml.com (July 08, 2003). "Last month, Sam Ruby threw the blogging world into a tizzy when he created a wiki to serve as the home for a new syndication format and protocol. This month we'll take a look at the project — the working name is 'Necho' but has been 'Echo' and 'Pie' at various times. We'll use it to motivate a look at tradeoffs in XML and web services design... Is this technically better than RSS? It clearly is better. The ambiguities are gone, the metadata is more precise, the ability to provide rich and accurate content is now provided, and the use of XML is quite clean. Unlike RSS, it's feasible to define a schema for Necho. DTDs, XML Schema, and Relax NG are all in the works. In other words, validation won't require a special-built validator. News aggregators and other RSS consumers — if they are written as XML applications — should have an easier job of presenting more information to their users. Generating a Necho feed does not look to be that much harder than generating an RSS feed, only requiring the tweaking of a few output statements or templates. Creating a Necho-to-RSS stylesheet in XSLT should be fairly straightforward. So from the technical front, it looks like everyone will win. Is it politically and socially better? The jury is still out. Radical format changes rarely win converts, and there are many who believe that the window of opportunity for change has already passed..."
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/atom.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org