A wholistic rss namespace for podcasting that is meant to synthesize the fragmented world of podcast namespaces. The broad goal is to create one namespace to rule them all, that is easily extensible, community controlled/authored and addresses the needs of the indie podcast industry now and in the future. The large podcast platforms have shown virtually no interest in extending their namespaces for new functionality in many years. Our hope is that this namespace will become the framework that the indie podcast community needs to deliver new functionality to apps and aggregators.
There is significant overlap amongst the many existing podcast namespaces. Each platform and publisher has created their own namespace to give their respective system and audience the metadata they need in the way they want it delivered.
Attributes in xml elements should be used only where absolutely needed. The preference is to create a new element type, rather than reuse the same element with different attributes. For example, instead of using <podcastindex:image type="Large">, we would use <podcastindex:imageLarge>. This makes the corresponding aggregator code easier and more linear.
The RSSv2.0 specification already has a robust set of defined elements. We should aim to use those instead of creating new ones. Instead of creating a <podcastindex:owner> element, we can use the already existing <managingEditor> element that contains both name and email address. In situations like item-level images, where the RSS spec never defined that element, it is appropriate to define new ones.
Reinventing the wheel helps nobody. When at all possible, existing conventions should be maintained. For example, it would make sense to turn <podcastindex:explicit> into a unary element, where it's existence is taken as a "yes" and it's absence as a "no". But, that has never been the standard. And, given as how this namespace will probably sit alongside at least one other namespace, it makes sense to keep existing conventions in place.
There is no way to address every possible metadata point that each platform would want. That is not the aim. Instead we focus on defining the elements that would be useful to the broadest set of apps, publishers, platforms and aggregators. Individual parties can keep their respective supplemental namespaces small and targeted as an adjunct to this larger namespace.
There can be a maximum of 9 category elements defined in a feed. Any number greater than that should be discarded.
Category names are defined in the accompanying "categories.json" file in this repository. They should be referenced in the element by their textual name. The characters can be in any case. This list of categories aims to replicate the current standard but also eliminate as much as possible compound, heirarchical naming and the use of ampersands. Thus, "Health & Fitness" becomes "Health" and "Fitness" as two distinct categories. And, "Religion & Spirituality" becomes two separate categories. Again, they are different things that don't always go together. Splitting them allows for more flexible combinations. And, avoiding ampersands makes xml encoding errors less likely.
If the "locked" element is present and set to "yes", podcasting hosts and platforms should not allow importing of this feed until the <podcastindex:email> or other defined feed owner (such as <managingEditor>) is contacted and subsequently sets the "locked" element to "no" or removes it from the feed.
The <podcastindex:previousUrl> element acts like a relay header in an email envelope. Each time a feed is imported, an additional <podcastindex:previousUrl> should be added, and all previous ones preserved.
Once a successful import has taken place, the <podcastindex:newFeedUrl> element can be put in the old feed as a pointer to the new location.
Their can be multiple <podcastindex:id> elements to indicate a listing on multiple platforms, directories, hosts, apps and services. If no "platform" attribute is given, the id string in the element is considered to be the registered Podcastindex.org ID. If the "platform" attribute is present, the element's value is taken as the ID of this podcast on that respective platform. The following slugs can be used:
More should be added over time by the community as needed. This is just a starter list.
There is an example feed in this repository showing the podcastindex namespace side by side with the Apple itunes namespace.