4 ms·

still dunno what's the difference between rss1.0, 2.0 and atom

by ilyt 3y ago

benoliver999 3y ago
I pick one at random, paste it into my feed reader, the feeds appear, hey presto!
gerikson 3y ago
Please read this comment that summarizes the situation: https://news.ycombinator.com/item?id=36378817 https://news.ycombinator.com/item?id=36378817
masklinn 3y ago
The TLDR is RSS is messy shit while Atom is well specified and works for anything you need outside of podcasts. As long as you don’t need to consume feeds, just use atom. The less TL is that RSS1 and RSS2 are basically two different branches of the original: - Netscape released RSS 0.90 as an RDF application (RSS literally stood for RDF Site Summary) - RSS 1.0 was an update / direct evolution of RSS 0.90 by a dedicated working group using final RDF 1.0 semantics (as RSS 0.90 had been based on an earlier working draft) - RSS 1.1 an evolution of RSS 1.0 by unrelated people This is called the RDF branch, for obvious reasons. However a few months after RSS 0.90 Netscape also released RSS 0.91, which dropped RDF entirely, rebranded to “Really Simple Syndication”, and added some elements from Userland’s own syndication format. This is the start of the “Harvard” (formerly “Userland”) branch, Userland / Dave Winer released his own variant of 0.91 (timeline with netscape has never been super clear to me), then went on to release 0.92 with an <enclosure> element, followed by 0.93 and 0.94. He then released RSS 2.0 to mark a bit of a compatibility break, as RSS 2.0 adds namespace support and removes some elements from his 0.9, and also to fuck with the RSS WG’s 1.0 release. Because the Harvard branch was the first to support enclosures (embedding audio) and Userland had built support for that, it became the de-facto format for podcast feeds, Atom also supports enclosures but I’m not sure any podcast client (or podcasting source) supports them.
- talideon 3y ago
  > As long as you don’t need to consume feeds, just use atom. Nah, you should just use Atom. The only vaguely good reason to use RSS is spotty Atom support in podcast apps. So, better formulation: only bother with RSS if you're a podcast.
  - masklinn 3y ago
    If you’re a feed client / consumer, you will have to parse RSS eventually, sadly.
- pferde 3y ago
  While RSS is, as you say, quite messy, Atom has also brought lots of headaches to this poor feed aggregator developer over the years. Its specification is a lot tighter than RSS', but there is still enough wiggle room for feed generators to get creative and make you want to strangle somebody.
  - jgalt212 3y ago
    sounds like Postel's law in play, but I agree it's annoying that there are incorrect / bad atom emitters. https://ardalis.com/postels-law-robustness-principle/ https://ardalis.com/postels-law-robustness-principle/
  - throw0101c 3y ago
    Perhaps time for RFC4287bis to tighten up the grey areas? Are there specific things that come to mind as specifically annoying?
    - pferde 3y ago
      It's been a long time since I spent my time on that, so I do not remember anything specific. But it was difficult figuring out reliably if a post in a given feed matched an already existing (locally cached) post, whether it was an updated version of that post, or whether if it was a completely new, hitherto unseen post, so it had something to do with the post IDs, timestamps and URLs.
x2rj 3y ago
Atom is an order of magnitude more complex and strict standard by people who really love xml in contrast to the really simple and less strict rss 2.0. For example almost everything is optional in rss 2.0 so you can have a reasonable feed for stuff like tweets or linkblogs where there is no obvious title. In contrast atom enforces a title for every item which makes this a messy expirience. I have implemented rss 2.0 parser faster then understanding the atom specification. Atom can do encode stuff like encode html inline the xml instead of as a CDATA string. In theory this sounds great, but is ends up in a big mess of complexity (e.g. a blogpost with handwritten invalid html). These days there is also JSONFeed which is really easy to parse, simple and flexible, but it is not supported everywhere yet.
- talideon 3y ago
  Atom is not a magnitude more complex or strict. It has _two_ places where it requires something even slightly onerous, and that's in the summary and content elements, where, shockingly, it allows you to specify if the content is XHTML, HTML, or text, and for HTML, it's just a matter of escaping the contents or putting it in CDATA. That's it. I don't know what you're doing that RSS 2.0 is somehow faster to parse than Atom. I've written parsers for both over the past twenty years with a negligible difference between the two besides the fact that the RSS feeds often need hacks. I've also wrote a whole bunch of blog and linkblog backends that produce Atom feeds, and have never and issue with any. Let's look at the required elements of an entry: updated, title, id. Nothing remotely onerous there. In fact, it's purposely minimal, more minimal than RSS. And in RSS 2.0, title is a required element (because if something it's explicitly noted as optional in the RSS 2.0 spec, it's assumed to be optional). In my personal linklog, I use the title of the target page of the link as the title, because it's the sensible option. With tweets, you have half a point. Only half a point, because title is required, but Twitter also post-dates the early 2000s considerably. But here's the thing: 'title' is required in RSS and Atom, but there's nothing saying it can't be empty. I know, I've blown your mind! And then there's JSONFeed, which, of course, can somehow gracefully cope with people dropping '"' in random parts of the file because people generate JSON files like that by hand, right? Right? Just like they write RSS and Atom feeds, right? Right?
- simonw 3y ago

still dunno what's the difference between rss1.0, 2.0 and atom

by ilyt 3y ago

still dunno what's the difference between rss1.0, 2.0 and atom

benoliver999 3y ago

I pick one at random, paste it into my feed reader, the feeds appear, hey presto!

gerikson 3y ago

Please read this comment that summarizes the situation: https://news.ycombinator.com/item?id=36378817 https://news.ycombinator.com/item?id=36378817

masklinn 3y ago

The TLDR is RSS is messy shit while Atom is well specified and works for anything you need outside of podcasts. As long as you don’t need to consume feeds, just use atom. The less TL is that RSS1 and RSS2 are basically two different branches of the original: - Netscape released RSS 0.90 as an RDF application (RSS literally stood for RDF Site Summary) - RSS 1.0 was an update / direct evolution of RSS 0.90 by a dedicated working group using final RDF 1.0 semantics (as RSS 0.90 had been based on an earlier working draft) - RSS 1.1 an evolution of RSS 1.0 by unrelated people This is called the RDF branch, for obvious reasons. However a few months after RSS 0.90 Netscape also released RSS 0.91, which dropped RDF entirely, rebranded to “Really Simple Syndication”, and added some elements from Userland’s own syndication format. This is the start of the “Harvard” (formerly “Userland”) branch, Userland / Dave Winer released his own variant of 0.91 (timeline with netscape has never been super clear to me), then went on to release 0.92 with an <enclosure> element, followed by 0.93 and 0.94. He then released RSS 2.0 to mark a bit of a compatibility break, as RSS 2.0 adds namespace support and removes some elements from his 0.9, and also to fuck with the RSS WG’s 1.0 release. Because the Harvard branch was the first to support enclosures (embedding audio) and Userland had built support for that, it became the de-facto format for podcast feeds, Atom also supports enclosures but I’m not sure any podcast client (or podcasting source) supports them.

talideon 3y ago
> As long as you don’t need to consume feeds, just use atom. Nah, you should just use Atom. The only vaguely good reason to use RSS is spotty Atom support in podcast apps. So, better formulation: only bother with RSS if you're a podcast.
- masklinn 3y ago
  If you’re a feed client / consumer, you will have to parse RSS eventually, sadly.
pferde 3y ago
While RSS is, as you say, quite messy, Atom has also brought lots of headaches to this poor feed aggregator developer over the years. Its specification is a lot tighter than RSS', but there is still enough wiggle room for feed generators to get creative and make you want to strangle somebody.
- jgalt212 3y ago
  sounds like Postel's law in play, but I agree it's annoying that there are incorrect / bad atom emitters. https://ardalis.com/postels-law-robustness-principle/ https://ardalis.com/postels-law-robustness-principle/
- throw0101c 3y ago
  Perhaps time for RFC4287bis to tighten up the grey areas? Are there specific things that come to mind as specifically annoying?
  - pferde 3y ago
    It's been a long time since I spent my time on that, so I do not remember anything specific. But it was difficult figuring out reliably if a post in a given feed matched an already existing (locally cached) post, whether it was an updated version of that post, or whether if it was a completely new, hitherto unseen post, so it had something to do with the post IDs, timestamps and URLs.

x2rj 3y ago

Atom is an order of magnitude more complex and strict standard by people who really love xml in contrast to the really simple and less strict rss 2.0. For example almost everything is optional in rss 2.0 so you can have a reasonable feed for stuff like tweets or linkblogs where there is no obvious title. In contrast atom enforces a title for every item which makes this a messy expirience. I have implemented rss 2.0 parser faster then understanding the atom specification. Atom can do encode stuff like encode html inline the xml instead of as a CDATA string. In theory this sounds great, but is ends up in a big mess of complexity (e.g. a blogpost with handwritten invalid html). These days there is also JSONFeed which is really easy to parse, simple and flexible, but it is not supported everywhere yet.

talideon 3y ago
Atom is not a magnitude more complex or strict. It has _two_ places where it requires something even slightly onerous, and that's in the summary and content elements, where, shockingly, it allows you to specify if the content is XHTML, HTML, or text, and for HTML, it's just a matter of escaping the contents or putting it in CDATA. That's it. I don't know what you're doing that RSS 2.0 is somehow faster to parse than Atom. I've written parsers for both over the past twenty years with a negligible difference between the two besides the fact that the RSS feeds often need hacks. I've also wrote a whole bunch of blog and linkblog backends that produce Atom feeds, and have never and issue with any. Let's look at the required elements of an entry: updated, title, id. Nothing remotely onerous there. In fact, it's purposely minimal, more minimal than RSS. And in RSS 2.0, title is a required element (because if something it's explicitly noted as optional in the RSS 2.0 spec, it's assumed to be optional). In my personal linklog, I use the title of the target page of the link as the title, because it's the sensible option. With tweets, you have half a point. Only half a point, because title is required, but Twitter also post-dates the early 2000s considerably. But here's the thing: 'title' is required in RSS and Atom, but there's nothing saying it can't be empty. I know, I've blown your mind! And then there's JSONFeed, which, of course, can somehow gracefully cope with people dropping '"' in random parts of the file because people generate JSON files like that by hand, right? Right? Just like they write RSS and Atom feeds, right? Right?
simonw 3y ago