Atom is the superior XML standard for syndication on the Internet. Atom is very well thought-out, offering all of the common features of RSS while improving on versatility and extensibility. Conversely, many of the most important features of RSS appear to have been duct-taped to the specification as an afterthought. When starting a new feed today, there is no reason to choose RSS over Atom.
When comparing applications of XML, RSS stands out as the odd one out. It doesn't conform to many conventions or standards commonly used with XML.
Atom is very much part of the XML ecosystem. It has an XML namespace, making it easy to include Atom elements in non-Atom XML. It also uses standards like xml:lang and xml:base which provide a universal format for certain metadata.
The Atom specification even includes rules for applying standard XML cryptographic signatures and encryption to feeds and entries, although this is very uncommon in the wild.
Although application/rss+xml is now widely understood to be the media type for an RSS feed and it's used by the RSS Advisory Board, it isn't officially registered with the IANA. This has led to some confusion in the past.
Atom's media type is application/atom+xml, which is registered with the IANA.
RSS uses RFC 822 timestamps (Fri, 04 Nov 2022 12:21:47 -0700) which are difficult to parse and sort. Atom uses RFC 3339 timestamps (2022-11-04T12:21:47-07:00), a much more modern format which makes things easier for developers and users alike.
The <description> element in RSS is either a "synopsis" of the item or full text of the item. There is no good way to tell which convention is followed by any given <description> element.
Additionally, the contents of the <description> element can either be entity-encoded HTML (which we'll talk about later) or not. Feed readers must probe the text contents of the element to see if it looks like HTML before rendering it as such.
This could have been been fixed very easily in the specification by defining an XML attribute to specify the content type, but RSS has no such attribute.
Atom solves both of these problems.
RSS has a <link> element to specify a URL pointing to the item on the Internet. There is also a <guid> element which is a string that uniquely identifies the item.
By default, the <guid> element also represents a "permalink" to the item on the Internet. Users must add the isPermaLink="false" attribute to the <guid> element to stop this behavior.
The specification does not define which should be preferred by a feed reader if an item has both a <link> element and a <guid> element with a missing or true isPermaLink attribute.
RSS also does not require an item to have a unique identifier, forcing feed readers to handle deduplication of incoming items based on the contents of other elements. Elements like <description> and <title> could change at any time, leading to duplicated entries in feed readers.
Atom has the mandatory <atom:id> element which must contain an IRI (an internationalized URI). However, this element is never used as a link to the resource; it exists purely as a unique identifier that should never change.
Atom's <atom:link> element is significantly more versatile than the <link> element in RSS. It has several attributes which can be used to specify relationships, languages, media types, and information sources, among other things.
The RSS specification does not specify the handling of relative URIs, e.g. /blog/20221109.html. This means that the HTML content of an item must be transformed, changing all relative URIs to absolute URIs.
Atom supports the xml:base attribute for resolving relative URIs.
RSS handles HTML content poorly. It has to be escaped, i.e. put into a form that can't be mistaken as XML data.
A common method for this is entity-encoding, meaning all the special characters used in XML (<>&") are encoded as XML character entities. Entity-encoded HTML looks like the following.
<a href="https://mckinley.cc/">My Website<a>
Another method is to put the HTML into a CDATA block, instructing the XML parser to treat anything within as text.
<![CDATA[<a href="https://mckinley.cc/">My Website<a>]]>
These methods are ugly, inefficient, error-prone, and they make the content difficult to work with. For example, Firefox-based browsers cannot properly display the content of an RSS feed when using a client-side XSLT stylesheet. The stylesheet can show the content on Chromium-based browsers if you use the disable-output-escaping attribute.
There has been an open bug report about this since before the first release of Phoenix, the Web browser that would eventually become Firefox.
Since not all HTML is valid XML, Atom still supports escaped HTML. However, if your HTML snippet is valid XHTML, it can be inserted directly into the document tree, like so.
<content type="xhtml"> <div xmlns="http://www.w3.org/1999/xhtml"> <a href="https://mckinley.cc/">My Website<a> </div> </content>
When the content is just part of the XML, it can be easily read and transformed like anything else.
Historically, there was a compatibility benefit to providing an RSS feed. Atom is much newer than RSS and took some time to attain the level of adoption had by its adversary. Now, Atom is probably supported in any feed reader your visitors are likely to be using.
Wikipedia has a list of 57 feed readers, of which 41 have been checked for Atom support. 39 out of those 41 support Atom. This is definitely not the most scientific analysis, but it still shows that Atom is supported in at least 39 of the most popular feed readers.
You can get all the benefits of the Atom format without any significant downside where compatibility is concerned.