Atom is technically substantially superior. RSS is an awful hack that leaves far too much to chance, such as in not specifying the format of fields that could be HTML or text. Probably the most significant thing is that Atom encodes whether a field is text or HTML. If you want your feed item’s title to contain things that could be parsed as HTML (e.g. “how to use the <hr> tag”), you’re in for a miserable time: some feed readers will treat it as plain text; some will treat it as HTML (and then probably strip out the <hr>); some may even double-encode it (“how to use the <hr> tag”). If you use Atom, you can specify that the title is plain text, so that the intent is clearly conveyed, and any client that mangles it in any of the aforementioned ways (and I’m not going to rule that out, though I’ve observed fewer problems with handling of Atom feeds) is clearly and definitely wrong. You can also use this to deliberately write HTML in your titles, e.g. <strong>, <em>, <code>. I like to do that, especially for <code>. Most readers will probably subsequently strip the HTML (which is a bit of a shame for inline formatting), but the idea is nice anyway, and more importantly it makes it clear what the correct way of handling it is, rather than leaving it unspecified and hoping for the best.
For normal feeds, I recommend developers use Atom every time. No need to subject yourself to the pain RSS engenders.
However, there’s one place where you still need to use RSS: podcast feeds. Most podcast software doesn’t support Atom, despite the fact that at the time when all that software was written RSS had been obsoleted by Atom. The industry just doesn’t seem to have realised Atom exists, which is stupid: they all just keep on copying one another instead, and adding their own namespace both to add their own fields and to fix the shortcomings of RSS, so that if you follow all of the recommendations from Apple, Spotify, &c. &c. you’ll end up with most of the fields written out in 3–6 different ways (e.g. <foo>…</foo>, <itunes:foo>…</itunes:foo>, <spotify:foo>…</spotify:foo>, <something-else:foo value="…"/>, that kind of thing).
Pretty much all progress in feeds happened between about 2002 and 2007. Roughly no documentation or review of the situation has been published since then. It’s a very unhealthy ecosystem.
Summary: RSS for podcast feeds, Atom for everything else.
For normal feeds, I recommend developers use Atom every time. No need to subject yourself to the pain RSS engenders.
However, there’s one place where you still need to use RSS: podcast feeds. Most podcast software doesn’t support Atom, despite the fact that at the time when all that software was written RSS had been obsoleted by Atom. The industry just doesn’t seem to have realised Atom exists, which is stupid: they all just keep on copying one another instead, and adding their own namespace both to add their own fields and to fix the shortcomings of RSS, so that if you follow all of the recommendations from Apple, Spotify, &c. &c. you’ll end up with most of the fields written out in 3–6 different ways (e.g. <foo>…</foo>, <itunes:foo>…</itunes:foo>, <spotify:foo>…</spotify:foo>, <something-else:foo value="…"/>, that kind of thing).
Pretty much all progress in feeds happened between about 2002 and 2007. Roughly no documentation or review of the situation has been published since then. It’s a very unhealthy ecosystem.
Summary: RSS for podcast feeds, Atom for everything else.
reply