Podcast data distribution format – RSS 2.0
farski opened this issue · comments
http://cyber.harvard.edu/rss/rss.html
RSS is a Web content syndication format. It is the de facto standard for podcast data distribution, and is universally adopted by podcast clients, publishing platforms, and aggregators. Despite its shortcomings, it should be adopted as the standard for the basis of ongoing work and technologies. Because it is based on XML and already has a history of being successfully extended by various parties, it will be possible to continue to improve on this foundation with further additions. The RSS 2.0 spec is frozen and represents a stable platform to start with.
Is this up for discussion? I know publishers like you should still use RSS for mass compatibility, and I don't see that ever changing. But not even a mention of Atom? I feel like you should have at least one comment somewhere recommending clients support it as well.
It is after all designed to plug the shortcomings of RSS, a more "native" XML structure and has full compatibility with RSS extensions. With the added bouns of going through a standards body and so is actually frozen, not just (kind of) abandoned.
@Cj-Malone Is there anyone out there doing anything with Atom in podcasting? I guess I'm just not sure what the benefit of a client supporting it would be. It seems impractical to drop support for RSS and no one has made a compelling argument that it's worth supporting and being highly opinionated about two very similar standards. What's the advantage of pushing RSS+Atom over RSS+JSON or something like that.
I guess where I come down on this is two fold. First, dealing with the current situation and making improvements in the short-term simply has to be RSS; trying to push anything else is a huge risk and likely to go nowhere. Second, thinking about the far out future of podcasting, it's certainly possible to see an ecosystem where RSS has been replaced. I have a tough time believing that the replacement would be Atom, though. Atom hasn't been picked by almost anyone in a world of increasing numbers of API's and open sources of data.
I don't want to make a recommendation that we expect to be ignored, and at the moment I'm not sure why we would be asking/expect developers to support two completely different formats that are extremely close and achieve the same goal.
I'm not suggesting a drop of RSS support, or even publishers using both. Just for a recommendation that clients do, not a requirement. And as far as I know there isn't a JSON standard?
I understand that you should be pushing RSS because of its wide spread adoption. But that is also an issue with RSS, I've never encounted a client that properly supports it. (See if the client you use supports the source element, or even differentiate between pubDate, lastBuildDate and ttl)
It's not about the recommendation being ignored, RSS is the foundation of this namespace and so you should at least be pushing proper support of RSS. And as the spec even recommends light use of Atom, I think you should too.
A huge part of the syndicated.media initiative is to change the fact that many apps don't implement RSS correctly or completely. There are many clients out there that do most of RSS correctly, even source, pubDate, ttl, etc. They may not be the majority, but they are out there. And every other client that mostly or partially implements RSS is much closer to a good, workable, future proof RSS spec than they are to an Atom spec. I totally get that Atom solves some problems, but even recommending it would be open ourselves up to the possibility that some number of clients, publishers, and shows we be starting over from scratch with a new spec that, unless someone presents some new facts, doesn't really get us closer to the things we want.
I may just be misunderstanding what you're proposing. It seems like you're saying a client should be able to optionally build in support for Atom feeds (ie a feed where an episode = an entry). If we're saying that such support is optional, it means that there's almost no reason for a publisher to ever producer an Atom feed, since there's a very good chance some apps won't be able to parse it, and there's a very slim chance that not every client will support RSS. Which leads us to a situation where both clients and publishers have one very obvious choice (RSS) and one more idealistic but largely useless choice (Atom). Clients likely wouldn't opt in to that support and extra dev work if there's no content, and publishers likely wouldn't choose to publish in Atom if there isn't universal support. We'd be left with a recommendation that, most likely, would almost never get used.
I don't think we have the luxury of being wishy-washy about a lot of the decisions we make, so a mere recommendation to support an entirely separate and additional data format just seems like a bad idea to me. I would still need to hear some actual, concrete examples of what Atom brings to the table and who is positioned and prepared to adopt it.