search

Podcastindex-org / podcast-namespace

A wholistic rss namespace for podcasting
Creative Commons Zero v1.0 Universal
380 stars 114 forks source link

Proposal: Reducing redundancies with feature parity #195

Open theDanielJLewis opened 3 years ago

theDanielJLewis commented 3 years ago

I believe we all agree that the Podcast namespace should eventually be a drop-in replacement to the "iTunes" namespace, but with a whole lot more features.

Inspired by #194, here's one potential example:

<itunes:image href="https://podnews.net/static/podnews-2000x2000.png" />
<podcast:image href="https://podnews.net/static/podnews-2000x2000.png" primaryColor="#B01212" secondaryColor="#1d2129" svg="https://podnews.net/static/podnews-2000x2000.svg" />

Imagine this same kind of issue with season numbers, episode numbers, "number-free" titles, and more. Pretty soon, you might end up nearly doubling the feed size simply because of repeating information in order to get it all in a single namespace while also continuing to support the widely supported (and unlikely to be retired) "iTunes" namespace.

So I propose that we build in redundancy-reducing specs, allowing redundant attributes to fallback to other tags.

The above example could be reduced to this:

<itunes:image href="https://podnews.net/static/podnews-2000x2000.png" />
<podcast:image primaryColor="#B01212" secondaryColor="#1d2129" svg="https://podnews.net/static/podnews-2000x2000.svg" />

Since href="https://podnews.net/static/podnews-2000x2000.png" was already defined in the prior standard, we could omit it from the Podcast image tag and save space.

The same could apply and scale very well for much larger tags, such as episode descriptions/summaries and <content:encoded>.

For example, <podcast:notes style="full" …> would fall back to the contents of <content:encoded> without having to duplicate those full contents. And <podcast:notes style="summary" …>" would fall back to the contents ofor`.

In other words, specific fallbacks by omission rather than explicit reference or duplication.

swschilke commented 3 years ago

Similar to the Google spec, where they defined / explanind everything in a Google namespace and wrote something like "if it starts with itunes it's okay as well" ;-)

But what if the Apple directory does not read the podcast namespace and therefore a podcast can not be registered at the Apple directory, hence you would have to have both tags / namespaces in parallel.

I assume Apple will not move towards the podcast namespace anytime soon.

.

jamescridland commented 3 years ago

I like your idea, Daniel, and have incorporated it in my categories reboot.

vv01f commented 3 years ago

I assume Apple will not move towards the podcast namespace anytime soon.

as soon as the free indizes take off in client side, that's their bad. ;) so dropping in itunes ns additionally could be optional, not default yes, to later make it default no.