Ah, I’d skipped ahead to the RSS page and missed that. I had been perplexed that it wasn’t even mentioned, but I’m glad to see that it was addressed earlier.
I disagree with the reasoning, because Atom is every bit as widely supported outside podcasting, and RSS is more painful to generate, requiring special-purpose date formatting rather than using the standard format that your library already supports, and requiring foolish duplication (things like description versus content:encoded) to obtain almost reliable results due to some of its underspecified or unspecified areas causing genuine pain for authors and clients alike, and simply not representing the right semantics. Atom is much more dependable and harder to mess up, and the sensible choice to implement as a feed producer, except (as mentioned) in podcasting where Apple froze it out.
I disagree with the reasoning, because Atom is every bit as widely supported outside podcasting, and RSS is more painful to generate, requiring special-purpose date formatting rather than using the standard format that your library already supports, and requiring foolish duplication (things like description versus content:encoded) to obtain almost reliable results due to some of its underspecified or unspecified areas causing genuine pain for authors and clients alike, and simply not representing the right semantics. Atom is much more dependable and harder to mess up, and the sensible choice to implement as a feed producer, except (as mentioned) in podcasting where Apple froze it out.