Hubbry Logo
Atom (web standard)Atom (web standard)Main
Open search
Atom (web standard)
Community hub
Atom (web standard)
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Atom (web standard)
Atom (web standard)
Atom (web standard)
View on Wikipedia
from Wikipedia

Atom
Filename extension
.atom, .xml
Internet media type
application/atom+xml
Developed byInternet Engineering Task Force
Initial releaseRFC 4287 December 2005; 19 years ago (2005-12)
Type of formatWeb syndication
Container forUpdates of a website and its related metadata (Web feed)
Extended fromXML
Open format?Yes
Websitewww.ietf.org/rfc/rfc4287.txt
User interface of a feed reader

The name Atom applies to a pair of related Web standards. The Atom Syndication Format is an XML language used for web feeds, while the Atom Publishing Protocol (AtomPub or APP) is a simple HTTP-based protocol for creating and updating web resources.[1]

Web feeds allow software programs to check for updates published on a website. To provide a web feed, the site owner may use specialized software (such as a content management system) that publishes a list (or "feed") of recent articles or content in a standardized, machine-readable format. The feed can then be downloaded by programs that use it, like websites that syndicate content from the feed, or by feed reader programs that allow internet users to subscribe to feeds and view their content.

A feed contains entries, which may be headlines, full-text articles, excerpts, summaries or links to content on a website along with various metadata.

The Atom format was developed as an alternative to RSS. Ben Trott, an advocate of the new format that became Atom, believed that RSS had limitations and flaws—such as lack of on-going innovation and its necessity to remain backward compatible—and that there were advantages to a fresh design.[1]

Proponents of the new format formed the IETF Atom Publishing Format and Protocol Workgroup. The Atom Syndication Format was published as an IETF proposed standard in RFC 4287 (December 2005), and the Atom Publishing Protocol was published as RFC 5023 (October 2007).

Usage

[edit]

The blogging community uses web feeds to share recent entries' headlines, full text, and even attached multimedia files.[2] The providers allow other websites to incorporate a blog's "syndicated" headline or headline-and-short-summary feeds under various usage agreements. As of 2016 people use Atom and other web-syndication formats for many purposes, including journalism, marketing, bug-reports, or any other activity involving periodic updates or publications. Atom also provides a standard way to export an entire blog, or parts of it, for backup or for importing into other blogging systems.

It is common to find web feeds on major websites, as well as on many smaller ones.[citation needed] Some websites let people choose between RSS- or Atom-formatted web feeds; others offer only RSS or only Atom. In particular, many blog and wiki sites offer their web feeds in the Atom format.

A feed reader or "aggregator" program can be used to check feeds and to display new articles. Client-side readers may also be designed as standalone programs or as extensions to existing programs like web browsers.

Web-based feed readers and news aggregators require no software installation and make the user's "feeds" available on any computer with web access. Some aggregators syndicate (combine) web feeds into new feeds, e.g., taking all football-related items from several sports feeds and providing a new football feed.

Atom compared to RSS 2.0

[edit]

When Atom emerged as a format intended to rival or replace RSS, CNET described the motivation of its creators as follows: "Winer's opponents are seeking a new format that would clarify RSS ambiguities, consolidate its multiple versions, expand its capabilities, and fall under the auspices of a traditional standards organization."[3]

A brief description of some of the ways Atom 1.0 differs from RSS 2.0 has been given by Tim Bray, who played a major role in the creation of Atom:[4]

Date formats

[edit]

The RSS 2.0 specification relies on the use of RFC 822 formatted timestamps to communicate information about when items in the feed were created and last updated. The Atom working group chose instead to use timestamps formatted according to the rules specified by RFC 3339 (which is a subset of ISO 8601; see Appendix A in RFC 3339 for differences).

Internationalization

[edit]

While the RSS vocabulary has a mechanism to indicate a human language for the feed, there is no way to specify a language for individual items or text elements. Atom, on the other hand, uses the standard xml:lang attribute to make it possible to specify a language context for every piece of human-readable content in the feed.

Atom also differs from RSS in that it supports the use of Internationalized Resource Identifiers, which allow links to resources and unique identifiers to contain characters outside the US ASCII character set.

Modularity

[edit]

The elements of the RSS vocabulary are not generally reusable in other XML vocabularies. The Atom syntax was specifically designed to allow elements to be reused outside the context of an Atom feed document. For instance, it is not uncommon to find atom:link elements being used within RSS 2.0 feeds.

Barriers to adoption

[edit]

Despite the emergence of Atom as an IETF Proposed Standard and the decision by major companies such as Google to embrace Atom, use of the older and better-known RSS formats has continued. There are several reasons for this:

  • RSS 2.0 support for enclosures led directly to the development of podcasting. While many podcasting applications support the use of Atom 1.0, RSS 2.0 remains the preferred format. While iTunes previously supported Atom,[5] it dropped support in 2023.[6] and requires podcasts to be in RSS 2.0 format.[7]
  • Many sites choose to publish their feeds in only a single format. For example, CNN and The New York Times offer their web feeds only in RSS 2.0 format.
  • News articles about web syndication feeds have increasingly used the term "RSS" to refer generically to any of the several variants of the RSS format such as RSS 2.0 and RSS 1.0 as well as the Atom format.[8][9]

Development history

[edit]

Background

[edit]

Before the creation of Atom the primary method of web content syndication was the RSS family of formats.

Members of the community who felt there were significant deficiencies with this family of formats were unable to make changes directly to RSS 2.0 because the official specification document stated that it was purposely frozen to ensure its stability.[10]

Initial work

[edit]

In June 2003, Sam Ruby set up a wiki to discuss what makes "a well-formed log entry".[11] This initial posting acted as a rallying point.[12] People quickly started using the wiki to discuss a new syndication format to address the shortcomings of RSS. It also became clear that the new format could form the basis of a more robust replacement for blog editing protocols such as the Blogger API and LiveJournal XML-RPC Client/Server Protocol as well.

The project aimed to develop a web syndication format that was:[13]

  • "100% vendor neutral,"
  • "implemented by everybody,"
  • "freely extensible by anybody, and"
  • "cleanly and thoroughly specified."

In short order, a project road map[13] was built. The effort quickly attracted more than 150 supporters, including David Sifry of Technorati, Mena Trott of Six Apart, Brad Fitzpatrick of LiveJournal, Jason Shellen of Blogger, Jeremy Zawodny of Yahoo, Timothy Appnel of the O'Reilly Network, Glenn Otis Brown of Creative Commons and Lawrence Lessig. Other notables supporting Atom include Mark Pilgrim, Tim Bray, Aaron Swartz, Joi Ito, and Jack Park.[14] Also, Dave Winer, the key figure behind RSS 2.0, gave tentative support to the new endeavor.[15]

After this point, discussion became chaotic, due to the lack of a decision-making process. The project also lacked a name, tentatively using "Pie," "Echo," "Atom," and "Whatever" (PEAW)[16] before settling on Atom. After releasing a project snapshot known as Atom 0.2 in early July 2003, discussion was shifted off the wiki.

Atom 0.3 and adoption by Google

[edit]

The discussion then moved to a newly set up mailing list. The next and final snapshot during this phase was Atom 0.3, released in December 2003. This version gained widespread adoption in syndication tools, and in particular it was added to several Google-related services, such as Blogger, Google News, and Gmail. Google's Data APIs (Beta) GData are based on Atom 1.0 and RSS 2.0.

Atom 1.0 and IETF standardization

[edit]

In 2004, discussions began about moving the project to a standards body such as the World Wide Web Consortium or the Internet Engineering Task Force (IETF). The group eventually chose the IETF and the Atompub working group[17] was formally set up in June 2004, finally giving the project a charter and process. The Atompub working group is co-chaired by Tim Bray (the co-editor of the XML specification) and Paul Hoffman. Initial development was focused on the syndication format.

The Atom Syndication Format was issued as a Proposed Standard in IETF RFC 4287 in December 2005. The co-editors were Mark Nottingham and Robert Sayre. This document is known as atompub-format in IETF's terminology. The Atom Publishing Protocol was issued as a Proposed Standard in IETF RFC 5023 in October 2007. Two other drafts have not been standardized.[18]

Example of an Atom 1.0 feed

[edit]

An example of a document in the Atom Syndication Format: 

<?xml version="1.0" encoding="utf-8"?>

<feed xmlns="http://www.w3.org/2005/Atom">

	<title>Example Feed</title>
	<subtitle>A subtitle.</subtitle>
	<link href="http://example.org/feed/" rel="self" />
	<link href="http://example.org/" />
	<id>urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6</id>
	<updated>2003-12-13T18:30:02Z</updated>
	
	
	<entry>
		<title>Atom-Powered Robots Run Amok</title>
		<link href="http://example.org/2003/12/13/atom03" />
		<link rel="alternate" type="text/html" href="http://example.org/2003/12/13/atom03.html"/>
		<link rel="edit" href="http://example.org/2003/12/13/atom03/edit"/>
		<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
        <published>2003-11-09T17:23:02Z</published>
		<updated>2003-12-13T18:30:02Z</updated>
		<summary>Some text.</summary>
		<content type="xhtml">
			<div xmlns="http://www.w3.org/1999/xhtml">
				<p>This is the entry content.</p>
			</div>
		</content>
		<author>
			<name>John Doe</name>
			<email>johndoe@example.com</email>
		</author>
	</entry>

</feed>

Including in HTML

[edit]

The following tag should be placed into the head of an HTML document to provide a link to an Atom feed. 

<link href="atom.xml" type="application/atom+xml" rel="alternate" title="Sitewide Atom feed" />

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Atom (web standard)

View on Grokipedia
from Grokipedia
The Atom web standard is an XML-based family of Internet specifications designed for the syndication, publication, and editing of web content and metadata. It encompasses the Atom Syndication Format, which defines a structured format for representing lists of related information known as "feeds" and individual "entries" (such as weblog posts or news items), and the Atom Publishing Protocol, which provides a simple HTTP-based mechanism for creating, updating, and deleting these resources. The Atom Syndication Format, formalized in RFC 4287 in December 2005, uses the namespace http://www.w3.org/2005/Atom and the application/atom+xml to structure documents with root elements atom:feed for collections of entries and atom:entry for discrete items. Each feed or entry includes required metadata like a unique identifier (atom:id), a title (atom:title), and an update timestamp (atom:updated formatted per RFC 3339), alongside optional elements for authors, content, summaries, and links. This format addresses limitations in earlier syndication standards like by providing clearer semantics, extensibility, and support for , enabling aggregation and distribution of content across websites and applications. Complementing the format, the Atom Publishing Protocol (AtomPub), specified in RFC 5023 in October 2007, operates over HTTP using standard methods such as GET, , PUT, and DELETE to manage within "workspaces" and "collections." It introduces service documents (media type application/atomsvc+xml) for discovering available collections and category documents for organizing entries, while extending Atom with link relations like "edit" for manipulation. Together, these components form a robust, interoperable standard for web feeds and , widely adopted in blogging platforms, news aggregators, and APIs prior to the rise of alternative formats like JSON-based feeds.

Introduction and Overview

Definition and Purpose

Atom is a standardized XML-based format developed by the (IETF) for syndicating and publishing web content, including blog entries, news articles, and podcasts. Defined in RFC 4287, the Atom Syndication Format specifies a flexible structure for creating and sharing discrete units of content known as "entries," which are aggregated into "feeds" representing collections of such items. This format enables efficient distribution and consumption of web-based information across diverse platforms and applications, promoting in content exchange. Complementing the syndication capabilities, Atom supports the Atom Publishing Protocol (AtomPub), outlined in RFC 5023, which provides a standardized mechanism for creating, editing, and deleting resources on remote servers using HTTP-based interactions. This protocol extends Atom's utility beyond mere distribution, allowing clients to interact dynamically with content repositories in a consistent manner. Together, these components address the need for a robust, extensible framework in management. As a successor to earlier formats like , Atom was designed to resolve ambiguities and inconsistencies in prior specifications, thereby enhancing clarity, consistency, and cross-system compatibility. It employs the http://www.w3.org/2005/Atom to ensure unambiguous identification of its elements within broader XML documents.

Key Features

Atom documents are required to use encoding exclusively, ensuring consistent handling of text across diverse systems and languages. This mandatory encoding supports internationalization through the use of Internationalized Resource Identifiers (IRIs) for URIs and the xml:lang attribute for language tagging on elements, allowing feeds to specify content in multiple languages without compatibility issues. The format enforces strict compliance with XML 1.0, requiring all documents to be well-formed. Central to this structure are the required root elements: the element, which serves as the container for collections of entries, and the element, which represents individual items within a feed. This structured approach promotes by providing a clear, predictable document model that parsers can rely on. Atom includes built-in support for categorization via the element, enabling the tagging of entries with terms and schemes for organization. Links are handled through the element, which uses rel attributes to define relationships such as "alternate" for alternative representations or "enclosure" for media attachments like audio or video files. These features facilitate richer metadata and resource discovery compared to simpler tagging systems. Extensibility is achieved through XML namespaces, permitting the inclusion of custom elements and attributes from other vocabularies without disrupting the core parser's ability to process standard Atom components. This modular design allows implementers to extend feeds for domain-specific needs, such as adding geospatial data or custom metadata, while maintaining . To enhance usability, Atom emphasizes human-readable semantics in its element names, such as for creator information and This design choice supports easier manual inspection and debugging of feeds.

Technical Specifications

Document Structure

An Atom document is a well-formed XML 1.0 instance that uses the namespace URI http://www.w3.org/2005/Atom with the conventional prefix atom:, typically beginning with an XML declaration such as <?xml version="1.0" encoding="utf-8"?>. This structure ensures interoperability and validation through XML parsers, forming the hierarchical foundation for syndication feeds and individual entries. The root element of an Atom Feed Document is <feed>, which encapsulates a collection of syndication items and associated metadata. It must include exactly one each of the <title>, <id>, and <updated> elements, along with one or more <author> elements (unless all contained <entry> elements provide their own authors). Additionally, the <feed> element contains zero or more <entry> child elements, each representing a discrete item in the feed, as well as optional metadata like <link> and <generator>. This organization allows the <feed> to serve as a for multiple related entries while providing overarching context, such as the feed's and last update time. In contrast, the root element of an Atom Entry Document is <entry>, which describes a single syndication item and mirrors the structure of <feed> but on a per-item basis. It requires exactly one each of <title>, <id> (a unique URI identifier), and <updated>, plus one or more <author> elements, with optional elements like <content> or <summary> for the item's body or abstract. The <entry> may also include <link> elements for related resources, enabling navigation within or beyond the document. The <link> element within either <feed> or <entry> provides hyperlinks to associated web resources, requiring an href attribute (a URI) and optionally attributes like rel (e.g., rel="self" for the document's URI or rel="alternate" for an representation), type, hreflang, title, and length. These facilitate discovery and traversal, such as pointing to full content or edit endpoints, without embedding the resources directly. Atom enforces a strict rule that each document contains exactly one —either <feed> or <entry>—with no nesting of <feed> elements permitted, ensuring a flat, predictable that simplifies and processing. Core elements like <author>, which specify person or entity details, appear in both contexts but are detailed further in specifications for individual tags. This design promotes modularity, where feeds aggregate entries while standalone entries support independent distribution.

Core Elements

The <title> element is a required text construct in Atom feeds and entries, serving as a human-readable string that conveys the title or headline of the . It includes a type attribute that specifies the rendering method, with possible values of "text" (, default), "" (HTML markup), or "" (namespaced XHTML); the content is language-sensitive and must be processed according to its type to avoid security issues like script injection. For example:

<title type="text">Atom-Powered Robots Run Amok</title>

<title type="text">Atom-Powered Robots Run Amok</title>

The <id> element provides a unique and permanent identifier for an Atom feed or entry, represented as an Internationalized Resource Identifier (IRI) or URI that must remain constant across all versions of the resource. It is required in both feeds and entries, designed to be opaque to clients—meaning generators should not expose internal identifiers—and processors compare them character-by-character for equality without normalization. Common forms include UUIDs or tag URIs, such as tag:example.com,2005:entry1, ensuring global uniqueness without relying on location-based identifiers like HTTP URLs. The <updated> element is a required date construct indicating the most recent instant of significant modification to the feed or entry, formatted according to RFC 3339. This helps clients detect changes and order entries chronologically, with details on the profile of RFC 3339 provided in the dedicated date and time formats subsection. An example is:

<updated>2003-12-13T18:30:02Z</updated>

<updated>2003-12-13T18:30:02Z</updated>

The <author> element is a person construct that identifies the agent responsible for the creation of a feed or entry, required unless the information is inherited from a parent <author> in the feed; it appears zero or more times per feed or entry. It contains up to three sub-elements: <name> (required, a human-readable string, language-sensitive), <uri> (optional, a single IRI identifying the author, at most one), and <email> (optional, a single RFC 2822 address specification, at most one). If multiple authors exist, multiple <author> elements are used, as in:

<author> <name>[John Doe](/page/John_Doe)</name> <uri>http://example.com/johndoe</uri> <email>[email protected]</email> </author>

<author> <name>[John Doe](/page/John_Doe)</name> <uri>http://example.com/johndoe</uri> <email>[email protected]</email> </author>

The <content> and <summary> elements handle representations of the resource's content, with <content> being optional and providing the full or primary content (inline or via reference), while <summary> offers a shorter excerpt or abstract. Both support a type attribute defaulting to "text", with valid values of "text", "html", or "xhtml"; for <summary>, other values represent an , while <content> may use additional media types (typically with the src attribute for non-text content). The <content> element may include an src attribute (IRI reference) for out-of-line content, in which case it must be empty; the <summary> is optional and should not duplicate the <title> or full <content>. For instance, <content> might embed directly:

<content type="xhtml"> <div xmlns="http://www.w3.org/1999/xhtml"> This is <b>[XHTML](/page/XHTML)</b> content. </div> </content>

<content type="xhtml"> <div xmlns="http://www.w3.org/1999/xhtml"> This is <b>[XHTML](/page/XHTML)</b> content. </div> </content>

The <category> element enables tagging and classification of feeds or entries, appearing zero or more times and conveying a single category through its required term attribute (a identifying the category). It may include optional attributes: scheme (an IRI defining the categorization scheme) and [label](/page/Label) (a human-readable, language-sensitive for display); categories are not hierarchical unless specified by the scheme. This structure allows for flexible, machine-readable labeling, such as:

<category term="categorization" scheme="http://example.com/categories" label="Example Category" />

<category term="categorization" scheme="http://example.com/categories" label="Example Category" />

Date and Time Formats

Atom feeds mandate the use of a standardized date-time format to ensure and precise temporal information across diverse implementations. Specifically, all date elements in Atom conform to the "date-time" production defined in RFC 3339, which is a profile of the standard. This choice promotes machine-readable timestamps that are unambiguous and sortable without additional parsing logic. The required format follows the structure YYYY-MM-DDThh:mm:ssZ, where the year is four digits, the month and day are two digits each, the time components (hours, minutes, seconds) are two digits each, and Z denotes UTC time. Alternatively, a numeric timezone offset can be specified, such as +01:00 or -05:30, to indicate the difference from UTC. For example, 2005-07-04T12:34:56+01:00 represents July 4, 2005, at 12:34:56 in a timezone one hour ahead of UTC. Fractional seconds are permitted after the seconds field (e.g., 2003-12-13T18:30:02.25Z), but the format must include full precision to the second if seconds are present—no partial dates or times are allowed, and no whitespace is permitted anywhere in the string. The uppercase T separator between date and time, along with uppercase Z for UTC, is strictly enforced to maintain consistency. This format applies to core date elements such as <updated>, which is mandatory in both feeds and entries to indicate the most recent modification, and <published>, which is optional in entries to denote the original date. If extensions introduce additional date elements like <created>, they must also adhere to the same RFC 3339 profile. Parsers are required to handle both UTC (Z) and offset notations to resolve any temporal ambiguities, ensuring that timestamps can be accurately compared and processed regardless of the originating timezone. In contrast to RSS 2.0, which employs the more flexible RFC 822 format for its <pubDate> element (e.g., Sun, 19 May 2002 15:21:36 GMT), Atom's strict adherence to RFC 3339 eliminates common parsing pitfalls. The RFC 822 style, reliant on English abbreviations for days and months with optional timezone names, often leads to errors such as localized text or invalid timezone identifiers, complicating automated validation and aggregation. By mandating a numeric, culture-agnostic representation, Atom reduces these interoperability issues and facilitates reliable chronological ordering in syndication workflows.

Internationalization and Namespaces

Atom documents must use as the to ensure compatibility and proper representation of multilingual content. This requirement aligns with the XML 1.0 specification, under which Atom is defined, and is reflected in the "application/atom+xml" where serves as the default and recommended charset. To support , any Atom element may include the xml:lang attribute, which specifies the natural language of the element and its descendants, following the rules in XML 1.0 Section 2.12. For instance, xml:lang="en-US" indicates , enabling processors to apply language-sensitive behaviors such as text processing or localization. This attribute is particularly useful for elements like atom:title or atom:content that convey human-readable text in potentially diverse linguistic contexts. Atom adheres to XML's handling of bidirectional text and right-to-left scripts, relying on the Unicode bidirectional algorithm to render mixed-direction content correctly, such as combining left-to-right Latin text with right-to-left . No additional Atom-specific rules are imposed; instead, implementers follow the bidirectional processing defined in XML and supporting standards like CSS for visual presentation. The core vocabulary of Atom is bound to the default identified by the URI http://www.w3.org/2005/Atom, which encompasses all standard elements like feed, entry, and link. Atom's extensibility is achieved through XML namespaces, allowing custom prefixes for foreign vocabularies without conflicting with the core namespace. For example, the prefix geo: might be used for GeoRSS elements to add geographic data, provided the namespace URI is properly declared in the document. Processors must handle such extensions gracefully: upon encountering unrecognized elements from other namespaces in permissible locations, they must not cease processing or generate errors, opting instead to ignore the unknown markup while proceeding with the Atom feed. Relative URIs within Atom content, such as in links or enclosures, are resolved using the xml:base attribute, which any element may carry to establish a base URI context per the XML Base specification. This mechanism supports modular extensions by enabling relative references to external resources without absolute paths.

Comparison to Other Formats

Differences with RSS 2.0

Atom and RSS 2.0, both XML-based syndication formats, exhibit several structural and semantic differences in their core elements, reflecting Atom's design goals for greater precision and extensibility. The Atom <feed> element, which serves as the container for syndication content, mandates the presence of an <id> (a unique IRI identifying the feed) and an <updated> element (indicating the last modification timestamp in RFC 3339 format), whereas the RSS 2.0 <channel> element treats equivalent identifiers like <guid> as optional and lacks a required update timestamp, relying instead on optional <pubDate> or <lastBuildDate> in a less rigid date format. Similarly, individual Atom <entry> elements require a unique <id> for each item, ensuring unambiguous identification, while RSS 2.0 <item> elements use an optional <guid> that is not required to be a URI and may be absent, potentially leading to identification ambiguities. In content representation, Atom's <content> element within an <entry> supports flexible types, including type="xml" to embed full, well-formed XML structures for rich content, whereas RSS 2.0's <description> element is limited to escaped text or within CDATA sections, restricting it to simpler textual or markup content without native XML embedding. information in Atom is handled through structured <author> elements that can include <name>, <uri>, and <email> sub-elements, allowing for detailed per-entry or per-feed authorship and supporting multiple authors; in contrast, RSS 2.0 provides a single, unstructured <author> string (typically an ) at the item level and a channel-level <managingEditor> that is also email-focused and optional. Links in Atom utilize the <link> element with attributes like rel (specifying relationships such as "alternate" or "self") and type (media type), enabling multiple contextual links per entry or feed; RSS 2.0, however, employs a single <link> element per <item> or <channel> that simply provides a URL without relational or type attributes, limiting its expressiveness. For categorization, Atom's <category> element includes required term and optional scheme and label attributes, supporting hierarchical or namespaced tagging; RSS 2.0's <category> element is simpler, with an optional domain attribute but no equivalent to schemes or labels for structured classification.
AspectAtomRSS 2.0
Feed Container<feed> requires <id> and <updated><channel> has no required ID or update timestamp; <pubDate> optional
Entry/Item ID<entry> mandates unique <id> (IRI)<item> has optional <guid> (not necessarily URI)
Content<content> allows XML embedding (type="xml")<description> limited to text/ in
AuthorStructured <author> with <name>, <uri>, <email>; multiple allowedUnstructured string; single per item/channel
Links<link> with rel, type attributes; multiple possibleSingle <link> without relations or types
Categories<category> with term, optional scheme, label<category> with optional domain attribute

Advantages over RSS

Atom's design emphasizes strict conformance to XML standards, requiring well-formed documents without reliance on DTDs, which contrasts with RSS 2.0's more permissive structure that often leads to ambiguities in interpretation. The IETF Atom identified issues in existing syndication formats like , including ambiguities from multiple variants that hindered and led to inconsistent handling across tools. This rigorous validation in Atom improves by minimizing parser errors; for instance, RSS's loose definitions have been shown to result in inconsistent handling across tools, whereas Atom's precise rules ensure uniform processing. As highlighted in analyses from the IETF Atom around 2005, these RSS ambiguities contributed to widespread validation issues in feeds, underscoring Atom's advantage in fostering reliable syndication. A key enhancement in Atom is its integration with the Atom Publishing Protocol (AtomPub), defined in RFC 5023, which provides a standardized HTTP-based mechanism for creating, editing, and deleting web resources using Atom formats. This protocol supports comprehensive publishing workflows, such as managing collections of entries and handling media resources, features entirely absent in 2.0, which lacks any formal specification for such operations. By enabling dynamic beyond mere syndication, AtomPub addresses a critical gap in , allowing for more robust applications like collaborative editing and automated updates. Atom offers greater semantic richness through elements like <atom:content>, which includes a type attribute specifying formats such as text, html, or xhtml, ensuring content is rendered accurately without misinterpretation. In contrast, RSS 2.0's <description> element treats content as escaped plain text or HTML, often leading to rendering errors when complex markup is involved, as parsers struggle with undefined handling rules. This explicit typing in Atom prevents such misrendering, supporting richer, more predictable display of entries across diverse clients. Finally, Atom's cleaner extension model utilizes XML namespaces to incorporate foreign elements without breaking compatibility, avoiding the version fragmentation seen in (e.g., 0.9, 1.0, 2.0), where each iteration introduced incompatibilities. This approach future-proofs Atom by allowing seamless evolution and modular additions, as extensions can be defined and validated independently, reducing the maintenance burdens that plagued development.

Modularity and Extensibility

Atom's design emphasizes modularity through its XML-based structure, allowing reusable constructs such as text, person, and date elements that can be applied across feeds and entries without altering the core specification. This modularity supports extensibility by permitting foreign markup from other namespaces in designated locations, ensuring that Atom processors ignore unknown elements rather than failing, which enables seamless integration of additional features. A key mechanism for extensibility is the use of , where elements from external vocabularies, such as those for threading, can be embedded without disrupting core . For instance, the <thr:in-reply-to> element from the Atom Threading Extensions indicates a response to a specific resource, using attributes like ref for a , and the core Atom parser bypasses it if unrecognized. This approach allows extensions to add functionality, like conversation tracking, while maintaining . Further extensibility is provided through the link relations registry, which standardizes values for the rel attribute in <atom:link> elements to define relationships between resources. Registered relations, such as "edit" for modifiable resources and "next" for pagination in feeds, enable structured navigation and manipulation without modifying the Atom format itself. The registry, maintained by IANA, supports both predefined and extension relations as URIs, promoting interoperability across implementations. The Threading Extensions illustrate this in practice by adding elements like <thr:total> to denote the total number of unique responses in a and <thr:count> for the number of replies linked via a rel="replies" attribute, both as non-negative integers for advisory purposes. These elements, prefixed with thr: from the http://purl.org/syndication/thread/1.0, enhance feed capabilities for tracking discussions without requiring changes to the base Atom specification. Media-related extensions are handled via the <atom:link> element with rel="enclosure", which points to large resources like audio files, including optional type for and length for size in bytes, as outlined in the Atom specification's appendix. This allows feeds to reference s reliably, with processors treating the link as opaque if the relation is unknown. In contrast to , where modules—particularly in RSS 1.0—rely on separate RDF-based specifications that often lead to parsing incompatibilities across implementations, Atom unifies extensions under a single XML framework with robust support. This unified approach permits most modules to be adapted into Atom feeds more fluidly, reducing fragmentation and enhancing overall compatibility.

Development History

Background and Initial Development

The rise of formats in the late was driven by the need to distribute frequently updated content, such as news headlines, across websites. In March 1999, Communications released 0.90, initially termed "RDF Site Summary," as part of its My.Netscape.Com portal to enable users to customize and aggregate channel content using RDF for metadata description. This format built on earlier ideas, including Dave Winer's Scripting News outline format from 1997, which Winer had developed to syndicate posts from his . By July 1999, updated the specification to RSS 0.91, simplifying it by removing RDF elements and incorporating additional features inspired by 's work, such as support for plain text descriptions. , then at UserLand Software, republished a version of RSS 0.91 in June 2000, followed by RSS 0.92 in December 2000 and RSS 2.0 in September 2002, which renamed the format "Really Simple Syndication" and emphasized ease of use for bloggers and publishers. Concurrently, in December 2000, the —comprising developers favoring modular, RDF-based designs—released RSS 1.0, introducing namespaces for extensibility but diverging significantly from 's simpler, non-RDF approach. This proliferation of competing specifications led to fragmentation in the syndication ecosystem, as tools and aggregators struggled with incompatibilities between RSS 1.0's RDF structure and the non-RDF versions like RSS 2.0, resulting in inconsistent parsing and limited interoperability across software. For instance, RSS 2.0's ambiguities, such as unclear rules for embedding HTML in the <description> element (e.g., whether to entity-encode tags, leading to double-escaping issues) and handling relative URIs without a defined base resolution, caused rendering failures in various aggregators. Date formats compounded these problems, with RSS allowing multiple conventions like RFC 822 without strict enforcement, making parsing error-prone and inconsistent across implementations. By early 2003, these challenges prompted calls for unification within the XML and web development communities. Discussions on platforms like XML.com highlighted the ongoing debate over RSS's evolution, with articles advocating for clearer standards to support growing adoption in blogging and news aggregation. Influential figures, including Tim Bray—one of the original XML specification co-editors—publicly critiqued RSS's shortcomings in blog posts, emphasizing the need for a simpler, more precise XML-based format to ensure reliable syndication without the "train-wreck" of escalating incompatibilities. Bray's motivations stemmed from his expertise in XML design principles, aiming to prioritize unambiguous specifications that developers could implement confidently. Similar sentiments appeared in IETF-related mailing lists and developer forums, underscoring the urgency for a community-driven solution to RSS's ambiguities ahead of broader web syndication growth.

Evolution to Atom 1.0

The development of the Atom syndication format originated in June 2003, when discussions initiated by Sam Ruby on the Intertwingly prompted to propose an initial draft known as the "Echo" format, intended to create a clean, extensible alternative to existing standards. This draft emphasized well-formed XML for syndication, drawing on Bray's experience as co-editor of the XML specification. Following community input, the project name evolved through several iterations—including "Pie" and "Whatever"—before settling on "Atom" after a multi-month debate on the , reflecting its goal of indivisible, atomic units of content. Subsequent snapshots incorporated feedback from bloggers and developers. Atom 0.1, released in July 2003, introduced basic schema definitions in , focusing on core elements like feeds and entries. Atom 0.2 followed in August 2003, refining the structure based on discussions on platforms like Tim Bray's "ongoing" blog, where participants debated extensibility and . By December 2003, Atom 0.3 emerged with simplified elements, such as streamlined date handling and metadata support, streamlining the format for practical use. This version saw early adoption by , which integrated it into Blogger in January 2004, enabling users to syndicate content in the new format and increasing Atom's exposure among millions of bloggers. In June 2004, the (IETF) established the Atom Publishing (atompub) to formalize the effort, co-chaired by and Paul Hoffman, with a core team of six developers including and Sam Ruby. The group built on the 's collaborative foundation, which had amassed over 1,500 pages of discussion from hundreds of contributors. This led to the release of the Atom 1.0 draft in July 2005, which finalized the syntax through iterative revisions addressing extensibility, , and compatibility concerns raised in deliberations.

Standardization Process

The IETF Atom Publishing Format and Protocol Working Group (atompub) was chartered in June 2004 to develop a standards-track specification for Atom syndication and a related publishing protocol, aiming to standardize a single feed format and editing mechanism for web resources such as weblogs and wikis, drawing on lessons from RSS while emphasizing interoperability, security, and extensibility. The charter specified submission of the Atom format document and protocol document as Proposed Standards to the IESG. Following development, the IESG issued a last call for comments on the Atom Syndication Format draft in April 2005, leading to revisions that addressed security vulnerabilities, such as potential information disclosure in feeds, and risks including unintended data sharing through syndication. These updates incorporated support for Internationalized Resource Identifiers (IRIs) as defined in RFC 3987 to handle non-ASCII characters securely in URIs within Atom documents. The revisions ensured compliance with XML and standards while mitigating risks like denial-of-service from malformed entries. The Atom Syndication Format was published as RFC 4287 in December 2005, establishing Atom 1.0 as a Proposed Standard for XML-based web content and metadata syndication. The companion Atom Publishing Protocol followed as RFC 5023 in October 2007, defining an HTTP-based application-level protocol for creating, editing, and deleting resources using Atom representations. Subsequent maintenance has involved processing minor errata for RFC 4287, such as clarifications on namespace usage and attribute validation, without necessitating major revisions or a bis draft; as of 2025, no newer RFC obsoletes it, preserving its status as the core specification. Atom's syndication and publishing model has influenced subsequent decentralized protocols, serving as a foundational reference for ActivityPub, a 2018 W3C recommendation enabling fediverse social networking through similar activity distribution and resource editing mechanisms.

Adoption and Challenges

Usage in Practice

Atom feeds continue to play a role in content syndication across various web services and tools, particularly in scenarios requiring structured XML-based distribution of updates. In blogging platforms, Atom support facilitates user subscriptions to new posts without relying on notifications or shares. For instance, includes native generation of Atom feeds, enabling seamless integration with feed readers for displaying content in a standardized format. Similarly, Blogger provides Atom feeds for exporting data and allowing subscriptions, which users can access via URLs like /feeds/posts/default. In API integrations, Atom has seen legacy application in RESTful services, though adoption has waned with the shift to formats. The API previously utilized Atom for data representation in its GData protocol; XML feeds were discontinued in November 2015 but remain in use for some legacy systems requiring XML syndication. News aggregators commonly parse Atom feeds alongside to broaden content discovery. Feedly's fetcher explicitly processes both RSS and Atom formats, allowing users to subscribe to diverse sources and receive real-time updates in a unified interface. This dual support ensures compatibility with publishers offering Atom as an alternative to RSS. For publishing workflows, the Atom Publishing Protocol (AtomPub) enables remote content editing in content management systems. Legacy modules like Drupal's AtomPub (last updated 2012) exposed site content for retrieval and manipulation over HTTP, though modern versions favor other protocols. In modern niches like , Atom's influence persists through protocols that extend its syndication principles. Mastodon's protocol builds on Atom-inspired concepts for federated feeds, using structured data to represent activities and enable across decentralized networks. Additionally, some podcast directories accept Atom feeds for episode listings, though 2.0 remains predominant; tools like Blubrry support Atom parsing to accommodate varied syndication needs in audio content distribution.

Barriers to Widespread Adoption

RSS 2.0 had already achieved significant entrenchment by 2003, when the Atom project began as an effort to address perceived shortcomings in , leading to a first-mover disadvantage for Atom as existing tools, aggregators, and user habits prioritized the established format. Atom's stricter compliance with XML specifications, including mandatory use of namespaces and well-formed parsing, created a of greater complexity compared to RSS's more forgiving and simpler structure, deterring casual developers and publishers from adopting it. Early web browsers, such as versions from 1.0 onward, provided native support for feeds via a prominent orange icon in the for easy subscription and preview, while Atom feeds lacked equivalent built-in visibility and often required extensions or dedicated readers for similar functionality. Major platforms exhibited vendor inertia, with early implementations like Google Blogger (launched in 2003) defaulting to feeds and only adding Atom support later, reinforcing dominance in ecosystems including and Outlook. Atom's share has since remained marginal, reflecting ongoing challenges in displacing .

Current Status and Legacy

The Atom Syndication Format (RFC 4287) and Atom Publishing Protocol (RFC 5023) have remained unchanged since their publication as IETF Proposed Standards in 2005 and 2007, respectively, with no subsequent updates or errata altering their core specifications. These documents continue to hold Proposed Standard status within the IETF, reflecting their stable but niche role in without progression to full due to limited evolution. In 2025, Atom maintains a presence in web feeds, with BuiltWith reporting approximately 2.6 million live websites using Atom feeds as of November 2025, though this represents a small fraction compared to 's over 37 million sites. Adoption persists more robustly in enterprise environments, where AtomPub enables structured interactions; for instance, IBM's Transaction Server and WebSphere Registry and Repository leverage the protocol for publishing and editing resources over HTTP. Atom's legacy endures through its influence on subsequent syndication technologies, serving as a foundational model for , the W3C Recommendation published in 2018 that enables real-time push notifications via HTTP web hooks for Atom and feeds. It also inspired , introduced in 2017 as a simpler JSON-based alternative to XML formats like Atom for content syndication, adopting similar structures for items, authors, and enclosures while prioritizing developer-friendly parsing. The 2013 shutdown of Google Reader, a major Atom-compatible feed aggregator, significantly diminished the broader ecosystem for syndication tools, accelerating the decline in casual consumer use. In the social web domain, alternatives such as ActivityStreams 2.0—formalized as a W3C Recommendation in 2017—have largely superseded Atom by providing a JSON-LD vocabulary tailored for activity data in decentralized networks like . Looking ahead, Atom's extensible framework positions it for potential revival in decentralized web initiatives, where protocols emphasizing user-controlled data sharing could leverage AtomPub's HTTP-based editing capabilities to integrate with emerging linked data standards.

Examples and Implementation

Sample Atom Feed

A sample Atom 1.0 feed demonstrates the practical structure of the syndication format as defined in the Atom specification, consisting of a root <feed> element that encapsulates metadata and one or more <entry> elements. The following example illustrates a basic multi-entry feed titled "Example Feed," with an opaque identifier, a current timestamp for the last update, and two entries containing HTML-formatted content; this feed could represent a blog or news aggregation.

xml

<?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <title>Example Feed</title> <id>tag:example.com,2005:feed</id> <updated>2025-11-09T10:00:00Z</updated> <link rel="self" href="https://example.com/feed.xml"/> <author> <name>[John Doe](/page/John_Doe)</name> <email>[email protected]</email> </author> <entry> <title>First Entry</title> <id>tag:example.com,2005:entry1</id> <updated>2025-11-09T09:00:00Z</updated> <author> <name>Jane Smith</name> </author> <content type="html"> &lt;p&gt;This is the first entry in the feed, discussing recent developments.&lt;/p&gt; </content> </entry> <entry> <title>Second Entry</title> <id>tag:example.com,2005:entry2</id> <updated>2025-11-09T08:00:00Z</updated> <author> <name>[John Doe](/page/John_Doe)</name> </author> <content type="html"> &lt;p&gt;This second entry provides additional updates.&lt;/p&gt; </content> </entry> </feed>

<?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <title>Example Feed</title> <id>tag:example.com,2005:feed</id> <updated>2025-11-09T10:00:00Z</updated> <link rel="self" href="https://example.com/feed.xml"/> <author> <name>[John Doe](/page/John_Doe)</name> <email>[email protected]</email> </author> <entry> <title>First Entry</title> <id>tag:example.com,2005:entry1</id> <updated>2025-11-09T09:00:00Z</updated> <author> <name>Jane Smith</name> </author> <content type="html"> &lt;p&gt;This is the first entry in the feed, discussing recent developments.&lt;/p&gt; </content> </entry> <entry> <title>Second Entry</title> <id>tag:example.com,2005:entry2</id> <updated>2025-11-09T08:00:00Z</updated> <author> <name>[John Doe](/page/John_Doe)</name> </author> <content type="html"> &lt;p&gt;This second entry provides additional updates.&lt;/p&gt; </content> </entry> </feed>

In this annotated example, the <title> element provides a human-readable name for the feed, while the <id> uses a URI-like tag scheme to uniquely identify it across systems, ensuring persistence and interoperability. The <updated> timestamp reflects the most recent modification to the feed, formatted in with Zulu time zone for global consistency. The <link rel="self" href="..." rel="nofollow"> specifies the feed's own URI, allowing clients to reference its location directly. Each <entry> mirrors this structure at a smaller scale, with its own <title>, <id>, <updated>, and <author> for attribution; the <content type="html"> holds the entry's body, escaped for XML safety to prevent parsing errors. To ensure a feed's validity, developers should validate it against the Atom schema using tools such as the W3C Feed Validation Service, which checks conformance to RFC 4287. Common errors include omitting the required <id> element in the feed or entries, which can cause aggregation failures, or using invalid date formats that deviate from the specified partial or full-date profile. Atom feeds support variations in structure: a multi-entry feed like the example above is typical for syndication, whereas a single-entry —containing just one <entry> without a surrounding <feed>—serves as a standalone Atom entry, useful for direct content publishing.

Embedding in HTML

Atom feeds can be embedded in HTML documents primarily through the use of the <link> element in the <head> section to enable autodiscovery by browsers and feed readers. This method allows web clients to automatically detect and offer subscription to the feed without manual configuration. The standard syntax is <link rel="alternate" type="application/atom+xml" href="feed.xml" rel="nofollow">, where rel="alternate" indicates an alternative representation of the page's content, type="application/atom+xml" specifies the Atom MIME type registered with IANA, and href points to the feed's URI. Autodiscovery for Atom feeds follows the conventions established in the Atom Syndication Format specification from 2005, where clients scan HTML documents for <link> elements matching the rel="alternate" attribute and the Atom media type. This practice extends earlier RSS autodiscovery techniques and is supported by modern browsers such as Chrome and , which parse these links to surface feed subscription options in their interfaces. For inline rendering of Atom feeds directly within an HTML page, developers traditionally used elements like <object> to embed the XML feed or JavaScript libraries (e.g., jQuery-based plugins) to fetch and display feed content dynamically. However, these approaches are largely deprecated due to security risks, including potential vulnerabilities from loading untrusted external XML or executing scripts in cross-origin contexts, which can expose sites to attacks like XML external entity (XXE) processing. Modern alternatives favor server-side rendering or secure client-side parsing with Content Security Policy (CSP) restrictions. Best practices for embedding include providing multiple <link> elements in the <head> to support both and Atom formats, allowing users to choose based on their preferred reader. For instance, one can include <link rel="alternate" type="application/rss+xml" href="feed.rss" rel="nofollow" title="RSS Feed"> alongside the Atom link, with the title attribute offering descriptive clarity for user interfaces. Feeds should use absolute URLs in href to ensure reliable resolution across environments. As of 2025, Atom feed embedding via <link> tags remains supported in major browsers like Chrome and for discovery purposes, though built-in feed readers have been phased out in favor of extensions. The rise of JSON-based alternatives, such as introduced in 2017, reflects a shift toward lighter, more web-native syndication formats amid declining reliance on XML feeds.

Common Extensions

One of the key strengths of the Atom syndication format is its extensibility through XML namespaces, allowing developers to add specialized functionality without altering the core specification. Common extensions enhance Atom feeds and entries with features like geolocation, threading for discussions, real-time notifications, and secure publishing protocols. These extensions are defined in separate standards and are widely adopted in applications such as blogging platforms, news aggregators, and systems. GeoRSS, introduced in 2006 by the Open Geospatial Consortium (OGC), enables the inclusion of geographic data in Atom feeds using simple XML elements. It supports basic geometries like points, lines, polygons, and boxes, making it suitable for entries with coordinates. For example, a point can be specified within an Atom entry as <georss:point>37.5 -122.4</georss:point>, where the values represent latitude and longitude, respectively. This extension uses the namespace http://www.georss.org/georss and is particularly useful for mapping and location-based services. The Atom Threading Extensions, defined in RFC 4685 (September 2006), provide a mechanism to represent threaded discussions within Atom feeds by linking entries as replies to resources. This allows feed consumers to reconstruct conversation hierarchies, such as comments or forum threads. A key element is <thr:in-reply-to ref="tag:example.com,2009:123" type="application/atom+xml">, which references the of the entry and specifies its ; an optional href attribute can point to the actual resource URI. The extension operates in the http://purl.org/syndication/thread/1.0 and includes additional elements like <thr:total> for counting replies. WebSub, standardized as a W3C Recommendation in January 2018 and formerly known as PubSubHubbub, facilitates real-time distribution of Atom feed updates through a publish-subscribe model using HTTP web hooks. Publishers notify hubs of changes, which then push updates to subscribers, reducing polling overhead for dynamic content like live blogs or social feeds. In an Atom feed, this is typically indicated by a link element such as <link rel="hub" href="https://pubsubhubbub.appspot.com" rel="nofollow">, pointing to a hub endpoint. The protocol supports Atom via its general web content mechanisms and has been implemented in services like . For secure publishing via the Atom Publishing Protocol (AtomPub, RFC 5023), 1.0 as specified in RFC 5849 (April 2010) provides an authentication framework for clients to access and edit resources on behalf of users. This extension integrates with HTTP requests in AtomPub workflows, such as creating or updating entries, by including OAuth signatures in headers to authorize actions without sharing credentials. It is commonly used in APIs for platforms like Blogger, ensuring delegated access while maintaining security over TLS. In practice, Atom feeds often incorporate these extensions to meet specific use cases, and parsers validate them using extended XML schemas that declare additional namespaces. This modular approach has enabled widespread customization while preserving interoperability with core Atom processors.

References

  1. https://datatracker.ietf.org/doc/html/rfc4287
  2. https://datatracker.ietf.org/doc/html/rfc5023
  3. https://www.rfc-editor.org/rfc/rfc4287
  4. https://datatracker.ietf.org/doc/html/rfc4287#section-4.2.14
  5. https://datatracker.ietf.org/doc/html/rfc4287#section-4.2.6
  6. https://datatracker.ietf.org/doc/html/rfc4287#section-4.2.15
  7. https://datatracker.ietf.org/doc/html/rfc4287#section-4.2.1
  8. https://datatracker.ietf.org/doc/html/rfc4287#section-4.1.3
  9. https://datatracker.ietf.org/doc/html/rfc4287#section-4.2.2
  10. https://datatracker.ietf.org/doc/html/rfc4287#section-3.3
  11. https://datatracker.ietf.org/doc/html/rfc3339
  12. https://datatracker.ietf.org/doc/html/rfc3339#section-5.6
  13. https://datatracker.ietf.org/doc/html/rfc4287#section-4.2.9
  14. https://datatracker.ietf.org/doc/html/rfc3339#section-5.1
  15. https://www.rssboard.org/rss-specification
  16. https://validator.w3.org/feed/docs/error/InvalidRFC2822Date.html
  17. https://datatracker.ietf.org/doc/html/rfc3023
  18. http://www.w3.org/TR/xmlbase/
  19. https://datatracker.ietf.org/doc/html/rfc4287#section-4.1.1
  20. https://datatracker.ietf.org/doc/html/rfc4287#section-4.1.2
  21. https://datatracker.ietf.org/doc/html/rfc4287#section-4.2.7
  22. https://datatracker.ietf.org/doc/html/rfc4287#section-4.2.3
  23. https://datatracker.ietf.org/doc/html/rfc4287#section-4.2.7.1
  24. https://datatracker.ietf.org/wg/atompub/charter/
  25. https://datatracker.ietf.org/doc/html/rfc4287#section-6
  26. https://datatracker.ietf.org/doc/html/rfc4685
  27. https://datatracker.ietf.org/doc/html/rfc8288
  28. https://validator.w3.org/feed/docs/atom.html
  29. https://www.rssboard.org/rss-history
  30. https://twobithistory.org/2018/12/18/rss.html
  31. https://www.tbray.org/ongoing/When/200x/2003/04/22/RSS-Problems
  32. https://www.mnot.net/blog/2003/04/29/rss_schema_and_dates
  33. https://www.xml.com/pub/a/2003/07/23/rssone.html
  34. https://web.archive.org/web/20121030042604/http://intertwingly.net/blog/1472.html
  35. https://www.rssboard.org/news/213/atom-feed-format-born-20-years-ago
  36. https://www.tbray.org/ongoing/When/200x/2003/07/09/PieSchema01
  37. https://www.tbray.org/ongoing/When/200x/2003/08/18/PieSchema02
  38. http://xml.coverpages.org/ni2003-10-22-a.html
  39. https://datatracker.ietf.org/doc/rfc4287/
  40. https://www.tbray.org/ongoing/When/200x/2005/07/14/Atom-1.0
  41. https://web.archive.org/web/20080913062709/http://www.intertwingly.net/wiki/pie/RoadMap
  42. https://www.ietf.org/proceedings/60/103.htm
  43. https://datatracker.ietf.org/doc/charter-ietf-atompub/
  44. http://xml.coverpages.org/ni2005-04-20-a.html
  45. https://datatracker.ietf.org/doc/html/rfc4287#ref-RFC3987
  46. https://datatracker.ietf.org/doc/html/rfc4287#section-8
  47. https://www.rfc-editor.org/info/rfc4287
  48. https://www.w3.org/TR/activitypub/
  49. https://www.wpbeginner.com/glossary/atom-2/
  50. https://support.google.com/blogger/thread/383876917/how-to-export-feed-atom-that-contains-not-more-than-10-posts?hl=en
  51. https://feedrabbit.com/blog/9-google-is-deprecating-calendar-xml-feeds
  52. https://feedly.com/fetcher.html
  53. https://www.drupal.org/project/atompub
  54. https://docs.joinmastodon.org/spec/activitypub/
  55. https://blubrry.com/manual/syndicating-your-podcast-rss-feeds/
  56. https://www.tutorialspoint.com/difference-between-rss-and-atom
  57. https://nullprogram.com/blog/2013/09/23/
  58. https://support.mozilla.org/en-US/kb/feed-reader-replacements-firefox
  59. https://support.google.com/blogger/thread/220498949/how-to-activate-rss-feed?hl=en
  60. https://wordpress.stackexchange.com/questions/2922/should-i-provide-rss-or-atom-feeds
  61. https://trends.builtwith.com/feeds/Atom
  62. https://trends.builtwith.com/feeds/RSS
  63. https://www.ibm.com/docs/en/cics-ts/6.x?topic=standards-atom-format-publishing-protocol-compliance
  64. https://www.w3.org/TR/websub/
  65. https://www.jsonfeed.org/version/1.1/
  66. https://www.cnn.com/2013/03/14/tech/web/google-reader-discontinued
  67. https://www.w3.org/TR/activitystreams-core/
  68. https://www.rfc-editor.org/rfc/rfc4287.html
  69. https://www.iana.org/assignments/media-types/application/atom+xml
  70. https://www.rssboard.org/rss-autodiscovery
  71. https://intertwingly.net/wiki/pie/PaceFormatSecurity
  72. https://www.mnot.net/rss/tutorial/
  73. https://developer.chrome.com/docs/web-platform/deprecating-xslt
  74. https://www.rfc-editor.org/rfc/rfc4685.html
  75. https://www.rfc-editor.org/rfc/rfc5023.html
Add your contribution
Related Hubs
User Avatar
No comments yet.