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
Created: April 20, 2005.
News: Cover StoriesPrevious News ItemNext News Item

IESG Issues Last Call Review for Atom Syndication Format as a Proposed Standard.

Contents

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.

The three "Container Elements" defined in the The Atom Syndication Format include the atom:feed element, the atom:entry element, and the atom:content element. The atom:feed element is the top-level (document, root) element of an Atom Feed Document, "acting as a container for metadata and data associated with the feed. Its element children consist of metadata elements followed by zero or more atom:entry child elements. The atom:entry element represents an individual entry, acting as a container for metadata and data associated with the entry. This element can appear as a child of the atom:feed element, or it can appear as the top-level element of a standalone Atom Entry Document.

The atom:content Element either contains the content of the entry or links to the content of the entry. The entry's content may be free-form character text, HTML, XHTML, or other (linked) content identified by a (non-composite) MIME media type.

The Atom specification's atom:content element is designed to support the inclusion of arbitrary foreign markup, incorporating markup constructs from other vocabularies. The processing rules for "unknown foreign markup" vary depending upon context and the type of Atom construct, but in all cases, an Atom processor must not stop processing or signal an error if "unknown foreign markup" in a well-formed Atom document is legal according to the conformance rules in the Atom specification.

The Atom Syndication Format defines "Person Constructs" and "Date Constructs" in addition to the common Text Constructs referenced above. A Person Construct is "an element that describes a person, corporation, or similar entity," and defined elements include atom:name (a language-sensitive, human-readable name for the person or entity), an atom:uri element which designates an IRI associated with the person, and an atom:email element which conveys an e-mail address associated with the person/entity, according to relevant rules in RFC 2822. A Date Construct is an element having content that conforms to the 'date-time' production in RFC 3339; these date values are compatible with ISO 8601, the W3C. NOTE 'datetime-19980827, and W3C XML Schema Part 2.

Atom metadata markup elements are designed for use with Atom feed and/or entry elements, with special rules for the semantics of (non-)inheritance down the element content hierarchy. These metadata elements include: atom:author [author of the entry or feed], atom:category [with term, scheme, label], atom:contributor, atom:copyright, atom:generator [agent used to generate a feed], atom:icon [image which provides iconic visual identification for a feed], atom:id [permanent, universally unique identifier for an entry or feed], atom:image, atom:link [empty element defining a reference to a Web resource], atom:published [date construct indicating an event early in the life cycle of the entry], atom:source [a feed from which an entry is copied], atom:subtitle, atom:summary [summary, abstract or excerpt of an entry], atom:title, and atom:updated [date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant].

Atom processors are required to respect XML security measures used by publishers of Atom feeds if these conform to the designated W3C Digital Signatures and XML Encryption specifications. "Because Atom is an XML-based format, these existing XML security mechanisms can be used to secure [Atom] content" as defined for the atom:feed, atom:entry, and other elements.

Bibliographic Information

Atom Publishing Protocol

A companion specification to The Atom Syndication Format is The Atom Publishing Protocol, currently at draft version -03. Excerpts:

The Atom Publishing Protocol "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 format is documented in the Atom Syndication Format...

The Atom Publishing Protocol Model: "The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources. The primary way of interaction in the Atom Publishing Protocol is by managing collection of resources. All collections support the same basic methods of interaction. In addition, the resources belonging to collections also share the same interaction patterns. Using the common HTTP verbs provides a pattern for working with all such Web resources:

  • GET is used to retrieve a representation of a resource or perform a read-only query
  • PUT is used to update a known resource
  • POST is used to create a new dynamically-named resource
  • DELETE is used to remove a resource..."

Atom Collections "An Atom collection is a set of items all of the same type ('members' of the collection), where the 'type' may be, for example: Atom entry, category, template, 'simple resource', or any other classification of web resource. Each collection has a URI which is given in the introspection file. A GET on the collection URI must produce a collection document... That document describes PART OF the state of the collection. All the members of a collection have an 'updated' property, and the collection is considered to be ordered by this property. A single collection document may not contain all of the members of a collection. If a collection document is the response of a non-partial GET request, and does not contain all of the members of a collection, then it will contain the URI of the next collection document which will contain more of the collection members. By traversing this list of collection documents a client can obtain all of the members of a collection. The 'next' attribute will not be present in the response to a partial GET request...

From the Atom Working Group Charter

According to the IETF Atom Publishing Format and Protocol (atompub) 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.

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.

Note from the Chair

Tim Bray (Sun Microsystems) is co-chair of the IETF Atom Publishing Format and Protocol (atompub) Working Group, along with Paul Hoffman. From Tim's Ongoing blog, ""IETF Last Call on the Atom Format"

This [Version -08] is a milestone: the IETF Atompub Working Group thinks we're mostly finished with the Atom Syndication Format, and our Area Director has put the draft out for last call IETF-wide. It's not set in stone, the WG is chewing on a couple of last little change proposals that might get consensus, and it's quite likely that some of the smart IETFers will spot problems and ask for changes. We think Atom does a reasonably good job of coalescing all the years of experience with all the RSSes, and I'm pretty convinced it will make a difference. We've tried to err on the side of omission; there are lots of things that could have been added that weren't. We only felt confident enough cover the areas where there's a lot of prior art and the arguments are mostly over. Anyhow, Atom's extensible; I'm pretty sure the market is creative enough to converge on good extensions to address any important things we left out. So please have a look either at the IETF ASCII or nice modern HTML versions of the draft, and see if you think we've missed anything..."

Principal References
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
Bottom Globe Image

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