Metadata link from website to podcast feed
farski opened this issue · comments
I think it would be good to encourage web pages for podcasts to include the podcast feed as a <link>, the same way many sites lists RSS feeds for blogs or comments. This would make the explicit connection between a website and a feed bidirectional, since nearly all feeds already link from the feed to the site. The only good rel value to use is alternate, which isn't ideal, but maybe there is another flag that could be required to indicate that the associated document is a podcast. Like data-podcast=true, but less dumb.
Second this idea. Having an explicit link to the RSS feed for a podcast on a webpage and being able to disambiguate which of the many links on a page is a/the podcast feed link would be beneficial. A data attribute on the link element seems like one of the few "valid" ways to accomplish this.
On Nov 11, 2016, at 7:06 AM, Chris Kalafarski notifications@github.com wrote:
I think it would be good to encourage web pages for podcasts to include the podcast feed as a , the same way many sites lists RSS feeds for blogs or comments. This would make the explicit connection between a website and a feed bidirectional, since nearly all feeds already link from the feed to the site. The only good rel value to use is alternate, which isn't ideal, but maybe there is another flag that could be required to indicate that the associated document is a podcast. Like data-podcast=true, but less dumb.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Assuming that the correct MIME type for rss is application/rss+xml (which I think it is, and which should also be explicitly standardized by this spec), my understanding is that it is possible to add arbitrary parameters to the standard type definitions. That could result in something like:
<link rel="alternate" href="/feed.xml" type="application/rss+xml;podcast=true">
Again, podcast=true is a bad system, but this generally is seems like a good option if we want to think about media types, which can be tricky. I need to read the spec to see if the parameters have to be KV pairs, or if we could just stick ;podcast on there and be done with it
A media type parameter need to be foo = bar, so maybe something like
application/rss+xml;syndication=podcast
I threw together a quick prototype of this
See <link> implementation here:
https://github.com/farski/www.bailey.dog/blob/gh-pages/index.html#L20
And a simple parser implementation here:
https://github.com/scour/podcasts-crx/blob/master/scripts/content.js#L106
I'm starting to like how this feels; would love some more feedback on the idea
@farski Are there any other potential values for syndication or is it just that structure to statisfy the key-value pair restriction?
@jgill333 I can imagine things like comment feeds and RSS feeds meant for reading being alternatives.
@farski I think maybe I would consider some way of differentiating for things like video, bitrates, media types, unless we want to recommend that all of that be put in a single feed using the media RSS type extensions
@chrisrhoden Does it make more sense for a show to have multiple feeds or for there to be one feed that offers multiple formats/bitrates?
Yeah, not sure. I guess my gut is for a single feed but I think multiple feeds is what most things in the wild do
The Podlove Publisher has been including links to podcast feeds since the beginning. We decided to use the <link rel="alternate" type="application/rss+xml" ...> approach:
<link rel="alternate" type="application/rss+xml" title="Podcast Feed: Newz of the World (MP3)" href="http://newz-of-the-world.com/feed/mp3/" />
<link rel="alternate" type="application/rss+xml" title="Podcast Feed: Newz of the World (M4A)" href="http://newz-of-the-world.com/feed/m4a/" />
<link rel="alternate" type="application/rss+xml" title="Podcast Feed: Newz of the World (Vorbis)" href="http://newz-of-the-world.com/feed/oga/" />
<link rel="alternate" type="application/rss+xml" title="Podcast Feed: Newz of the World (Ogg Opus)" href="http://newz-of-the-world.com/feed/opus/" />
However, I do see problems with this as these entries are not directly refering to "podcast feeds". as the <link> element does not allow any futher attributes to describe the link.
So it would be good to come up with a new namespace with elements that actively
- declare a web page to REPRESENT a podcast in general (HOME PAGE)
- declare a web page to REPRESENT a podcast episode (EPISODE PAGE)
- refer to podcast feeds explicitly listing URLs, enclosure types and maybe other meta information.
To kill ambiguity, it would be good to generally come up with a PODCAST URI, that should be used in these cases as well as in the podcast feed.
I have given top-level elements in podcast feeds a thought in my draft spec for the proposed Podlove Syndication Extensions (please note this is unfinished work mainly trying to collect some general thoughts about this):
https://github.com/podlove/podlove-specifications/blob/master/podlove-syndication-extensions.md
@timpritlove I am generally wary of attempting to extend HTML (even to the extent that it is related to XML and has some of the same extension characteristics of other SGML-family languages) as browsers are hard to get movement on. It seems to me that introducing the additional information after type has the problem of failing on backwards-compatibility for apps using simple string matching against application/rss+xml, but that can be combatted by including both a legacy formatted link tag and the one with the new values (everything post-semicolon).
I guess my gut is for a single feed but I think multiple feeds is what most things in the wild do
That's true, but the use of multiple feeds is a symptom of no leadership in this area, rather than an intrinsically-desirable thing.
A canonical URL for a podcast has many advantages. The primary benefit is "responsive podcasts", where apps can default to the best experience of a show given current constraints (network quality and kind, device capabilities), and even improving the experience mid-listen as the user roams from (for example) metered 3G to unmetered Wi-Fi.
"One feed, one show" also simplifies feed management for podcasters and directories, and will improve discovery (by reducing duplicate listings) and reduce confusion ("which do I subscribe to?") for audiences.
@chrisrhoden
It seems to me that introducing the additional information after type has the problem of failing on backwards-compatibility for apps using simple string matching against application/rss+xml
AFAIK, the number of websites that currently <link> to podcast feeds, especially for the top 1% of shows, is approaching zero. If there are any apps out there using link tags to find information about feeds, they're already failing. I agree that your solution for backwards compat. makes sense, but honestly this is one area where we probably can just ignore it. (Unless, of course, someone has evidence to the contrary)
A canonical URL for a podcast has many advantages. The primary benefit is "responsive podcasts", where apps can default to the best experience of a show given current constraints
Can you elaborate on that? Wouldn't "responsive podcasts" require multiple feeds? At least one for high-quality and one for low-quality media.
To add to the rest of the discussion: Assuming multiple media formats are desirable[1], the <link> should reveal the contained media format (file extension, mime type or both) as well as a quality indicator (like "hq" / "lq" or a precise kb/s number).
[1]: If this is disputed, it should probably be discussed in a separate topic. However, there's a reason the HTML5 audio tag support multiple sources. The more we can provide, the better the experience for the listener. Especially with mp3 being the de facto standard while being inefficient, compared to modern formats like opus, which sounds good even at 48kb/s (proof)
@eteubert I think I can fill in here - the thinking is that we could use some extensions to mediaRSS that would permit each item to have multiple representations in different file formats. Rather than using the current standard of having multiple feeds, we would have multiple formats / quality levels encoded in the same feed.
Exactly, thank you @chrisrhoden!
I also want to add that <link/> tags are also valid HTTP headers (Link is the header), so we can't just add data-podcast="true". I would vote for adding an IANA registration for ; syndicated=podcast (or something similar). Also, I think multiple feeds for each format is a mistake; MediaRSS lets you specify different formats in the <item/>, like you guys have come across.
@ziggythehamster do you know what the process for IANA registration looks like?
Yeah. It's not really that complicated. The original developers of RSS started the IANA type registration process but never finished it. Since then, the process got simpler. Now, it's just a form that asks for the same information.
The existing registration defines charset and revision; we'd want to add content="podcast" or something similar.