Why Atom instead of RSS? I understand the differences between the two formats[1] but I am curious what it is about Atom that caused the maker of this project to choose it over RSS.
Atom is technically substantially superior to RSS. RSS is riddled with ambiguities which lead to inconsistency of interpretation, and being outright unable to express some useful things.
My favourite is the format of all content: is it HTML or text? RSS doesn’t care, and leaves you to guess. So people added a namespace to fix that up, and you end up with what I think is normally spelled <content:encoded> to replace <description> or whatever it is—but there’s no equivalent for other content fields like titles. And because you can’t trust that tool will use <content:encoded>, now you need both. (And when you get to podcasts, the theme of the day is having the same field expressed in four or five different namespaces for different tools, in some cases for things that Atom has but RSS lacks.)
I have an article on my blog entitled <_>::v::<_>. I expect that a few RSS readers would mangle it if I served an RSS feed, but I serve an Atom feed, so I can express the title correctly:
(Bet you didn’t anticipate the <code> wrapping of that title! Now try that in RSS!) Anyway, NewsBlur got it right, and if any other client gets it wrong I can point to it and say that it is unequivocally a bug, whereas with RSS… eh, there’s enough ambiguity to drive a spaceship through, so what does “bug” even mean?
I hate the way that feeds are so commonly generically called “RSS”, because it gives mindshare to the bad and inferior product.
The only reason you should ever use RSS feeds is because you’re dealing with podcasts, because Apple sadly ignored the emerging Atom format when they did podcasts in iTunes in 2005, and annoyingly froze things in time there and then, and everyone else stupidly followed them, so that most of the major podcast things don’t support Atom… even if they sometimes claim to. (Like validation tools that allege that Atom is fine, butcher it completely if you give it to them, and report false results like that this RSS feed is fine or whatnot.)
I am a paying NewsBlur customer and like it very much.
It is, however, too picky about atom/rss - if you have a feed with some wrong entries (e.g. the one from freshcode.club) it will discard the problem items without a warning while still showing the valid items.
I wonder why anyone would still use RSS over Atom. Atom was already supported by virtually all feed readers when Google Reader was shut down. And that was nearly 8 years ago.
The only reason I can think of is that people often use RSS synonymously to feeds.
RSS is useful as a creator because it's so under-specified that you can create valid RSS with virtually no effort (ie: printf). It's a huge pain to consume it because every single library needs to have crazy hacks to do things like double-unescaping HTML.
Atom is the better format, but - like any time you work with XML - you should never try to hand-bomb string output. Use an XML library, or preferably an Atom library.
I’d be far happier emitting Atom via printf than RSS via printf. The Atom spec tells me what I should write, whereas RSS goes in for unspecified behaviour and exotic date formats that force me to look up strftime. Beyond that, they’re both XML, which is easy to write.
That article also has an XHTML 1.0 Transitional DOCTYPE, and wastes a request trying to load JavasScript for Google Plus.... this is not up-to-date information.
The "advantages" are minor at best, and exclusively relevant to a developer, with very little impact on the end-user
I have one or two things in my feeds that can’t be expressed in RSS, such as HTML markup in my titles (which I use for <strong>, <code> and I think <em>). I also have angle brackets in a title, which I would be afraid to do in RSS because I’m confident that some clients would butcher it, and they wouldn’t even be wrong since RSS don’t care.
This, to me, makes me ask what the purpose of a feed even is. If it's to deliver data then RSS, Atom, JSON, or YAML shouldn't make any different at all. But if it's to deliver data and markup... now we're making decisions a client could override at best or result in unreadable/a11y unfriendly content at worst. Maybe it's just me but I've never considered the feed as a place to be putting markup but even if we want to go that route then RSS's <![CDATA[ ... ]]> addresses this. What am I missing?
CDATA is purely a convenient way of encoding character data, of avoiding needing to escape <, & and > all the time. It doesn’t change the semantics at all, and if any client does vary the semantics based on this, it is wrong to do so.
RSS doesn’t say what format any of its content is in. You have to guess if it’s plain text or HTML. This can easily go wrong. The result is that you can’t trust the handling of characters like <, & and > in titles or in supposedly-plain-text descriptions in RSS feeds.
Markup's part of the data. Particularly in chrismorgan's example, where it's semantic content.
As for CDATA, I think you're right that it'd work in this case (assuming that client apps cope with it there, but if the Atom equivalent works then presumably it should).
I suspect that what we're looking at here is software which is poorly generating its RSS. Probably Wordpress, since I'm at least fairly confident that it doesn't put CDATA in its item titles regardless of their content.
I wasn't expressing any opinion one way or the other, nor did I provide the article as a reference. The original commenter seemed to be questioning the choice of Atom over RSS, and that article is what they posted as their reference; which seemed odd to me since it argues for using Atom over RSS.
Why would you consider RSS over Atom (you seem to exhibit a preference but you have also neglected to list any of the reasons)?
[1] http://www.differencebetween.net/technology/difference-betwe...