Proposal: <podcast:updateFrequency> tag

[nathangathright]

I’m creating a Discussion for this tag to be included in phase 6. Prior conversations were archived when the PR was merged. Additionally, since the initial proposal, I’ve built a sample UI implementation to show how a host might implement this in their own dashboards.

Purpose

In the spirit of taking platform-specific innovations and making them accessible to the open ecosystem of RSS, the intent of this proposal is to replicate the purpose of the “Update Frequency” field in Apple Podcasts Connect as well as replace the <itunes:complete> tag for podcasts that have no intention to release further episodes.

Additionally, apps like Overcast, Pocket Casts, and Podchaser analyze the intervals between past episodes to estimate a prediction for future releases. Under certain conditions or naive algorithms, this can be inaccurate:

• New podcasts that only have a trailer
• Limited-run podcasts nearing the end of a season
• “Daily” podcasts that only release on weekdays
• Podcasts with consistent releases at irregular intervals (every Monday and Wednesday)

If podcasters can unambiguously communicate their release schedule, then more apps can provide accurate information to their listeners.

Parent

<channel>

Count

Single

Node value

The node value is a free-form string, which might be displayed alongside other information about the podcast. Please do not exceed 128 characters for the node value or it may be truncated by aggregators.

Attributes

• complete (optional): Boolean specifying if the podcast has no intention to release further episodes. If not set, this should be assumed to be false.
• dtstart (optional): The date or datetime the recurrence rule begins. If the rrule contains a value for COUNT, then this attribute is required. If the rrule contains a value for UNTIL, then the value of this attribute must be formatted to the same date/datetime standard.
• rrule (recommended): A recurrence rule as defined in iCalendar RFC 5545 Section 3.3.10. Podcasters should not be expected to be able to write a valid recurrence rule themselves. There are several libraries to generate valid recurrence rules from form data or natural language text inputs.

Examples

Recreating most of Apple Podcasts Connect’s “Update Frequency” values is easily achieved:

<podcast:updateFrequency rrule="FREQ=DAILY">Daily</podcast:updateFrequency>
<podcast:updateFrequency rrule="FREQ=WEEKLY">Weekly</podcast:updateFrequency>
<podcast:updateFrequency rrule="FREQ=WEEKLY;INTERVAL=2">Biweekly</podcast:updateFrequency>
<podcast:updateFrequency rrule="FREQ=MONTHLY">Monthly</podcast:updateFrequency>
<podcast:updateFrequency rrule="FREQ=MONTHLY;INTERVAL=2">Bimonthly</podcast:updateFrequency>
<podcast:updateFrequency rrule="FREQ=MONTHLY">Monthly</podcast:updateFrequency>
<podcast:updateFrequency rrule="FREQ=YEARLY">Yearly</podcast:updateFrequency>

However, greater precision can be easily communicated:

<podcast:updateFrequency rrule="FREQ=DAILY;INTERVAL=1;BYDAY=MO,TU,WE,TH,FR">Every weekday</podcast:updateFrequency>
<podcast:updateFrequency rrule="FREQ=WEEKLY;BYDAY=MO,WE">Every Monday and Wednesday</podcast:updateFrequency>
<podcast:updateFrequency rrule="FREQ=WEEKLY;BYDAY=FR;BYMONTHDAY=13">Every friday the 13th</podcast:updateFrequency>
<podcast:updateFrequency rrule="FREQ=YEARLY;BYDAY=+4TH;BYMONTH=11">Every year on American Thanksgiving</podcast:updateFrequency>

Limited-run series can set expectations clearly:

<podcast:updateFrequency rrule="FREQ=WEEKLY;INTERVAL=2;BYDAY=MO;COUNT=10" dtstart="20230828">Every other Monday for 10 episodes starting on Aug 28, 2023</podcast:updateFrequency>
<podcast:updateFrequency rrule="FREQ=WEEKLY;UNTIL=20231231;BYDAY=MO">Every Monday until Dec 31, 2023</podcast:updateFrequency>

Completed series with no intention to release further episodes:

<podcast:updateFrequency complete="true">That’s all folks!</podcast:updateFrequency>

[jamescridland]

This looks a very sensible proposal. I've implemented it on the Podnews RSS feed should anyone need a test. I'd be particularly keen to hear from those in the audio fiction space to see if this works for them.

[brianoflondon]

Any reason not to use the Cron format?

It's pretty flexible and without looking there must be a ton of libraries to deal with it.

Years might have to be added.

[theDanielJLewis]

Podcasters should not be expected to be able to write a valid recurrence rule themselves

That part concerns me. I think it violates the foundation of podcasting. (See update in my comment below.)

And here I come with thoughts to improve simplicity, clarity, understandability, and optimization:

1. Do we really want to allow camel case updateFrequency instead of simply frequency? This isn't radio, and the word "frequency" wouldn't seem to have any other meanings for a podcast.
2. Why dtstart instead of datestart or startdate?
3. Why camel case the tag itself but not its attributes?

[jamescridland]

That part concerns me. I think it violates the foundation of podcasting.

I'd love more clarity on this foundation of podcasting of which you speak. But this UX example is really good, and is absolutely ideal.

[theDanielJLewis]

It was the "not be able to" thing.

It seems like all the other parts of a podcast feed can be fairly easily understood and populated with a simple text editor, and I think that was the original intention of XML (and RSS by extension). But getting into camel case and situations like rrule requiring advanced knowledge or a specific UI start complicating things.

But, on reviewing @nathangathright's examples, I realize I missed that the tag can have a plain-text value and the advanced attributes are optional. So I actually now think that strikes a good balance after all.

[nathangathright]

1. I picked Update Frequency to be consistent with the field in Apple Podcasts Connect.
2. I picked dtstart to be consistent with iCalendar RFC 5545
3. I picked camelCase to be consistent with the other two-word namespace tags alternateEnclosure and socialInteract. I have no objection to making the attributes camelCase.

[theDanielJLewis]

If we wanted to let podcasters indicate when their podcast launched, do you think that would be relevant to this tag, or something completely separate?

[daveajones]

That should be a separate tag.

[daveajones]

Thanks for writing this up as a discussion. Including it in Phase 6 announcement draft for consideration.

[picard102]

Is this meant to replace the sy:updateFrequency tag as well

[theDanielJLewis]

I would think so. But yikes, their approach is cumbersome!

[nathangathright]

According to the Syndication spec, the tag is defined as:

Provides syndication hints to aggregators and others picking up this RDF Site Summary (RSS) feed regarding how often it is updated.

If I’m reading that right, I don’t think sy:updateFrequency has anything to do with the frequency of new content in the feed, just how often the feeds are updated (whether there’s new content or not). We already have podping to tell aggregators when to check feeds. This is more listener-facing than aggregator-facing.

[theDanielJLewis]

There's a typo. Is the attribute complete or completed? It's written both ways in the proposal.

(I suggest completed.)

[nathangathright]

Thanks for catching this. To be consistent with the <itunes:complete>, I think we should stick with that.

[samsethi]

I recall a tag called Status that was previously discussed. Can't find it now. But one of the attributes was Hiatus. This Buzzsprout podcast is taking a break. How do we capture that status in the new UpdateFrequency. Or is this status for another tag. It would be really helpful for App developers to create a blacklist to place a temporary hold alongside another list for complete.

[nathangathright]

IMO, the updateFrequency tag is excellent for this use case. If the podcast uses this tag, client apps can know that a show is on hiatus as soon as the final episode drops, which isn’t possible with existing methodologies. Whenever the updateFrequency expresses a schedule that has no future episodes, we can conclude that the show is on hiatus.

Maybe initially, the podcaster thinks this show will go on indefinitely. Their updateFrequency could look like this:

<podcast:updateFrequency dtstart="2019-06-05" rrule="FREQ=WEEKLY;BYDAY=WE,FR">Every week on Wednesdays and Fridays</podcast:updateFrequency>

Once they’ve decided the show will only go for a limited run, they can express that by adding a UNTIL date or a COUNT:

<podcast:updateFrequency dtstart="2019-06-05" rrule="FREQ=WEEKLY;BYDAY=WE,FR;UNTIL=2019-08-28">Every week on Wednesdays and Fridays until August 28, 2019</podcast:updateFrequency>

<podcast:updateFrequency dtstart="2019-06-05" rrule="FREQ=WEEKLY;BYDAY=WE,FR;COUNT=25">Every week on Wednesdays and Fridays for 25 episodes</podcast:updateFrequency>

If an app determines that we’re past the UNTIL date or the COUNT, they can immediately mark the show as "On a break or finished". If a podcast doesn’t want to be marked as on hiatus, they could replace their updateFrequency with a new one starting in the future.

<podcast:updateFrequency dtstart="2024-01-03" rrule="FREQ=WEEKLY;BYDAY=WE,FR">Every week on Wednesdays and Fridays</podcast:updateFrequency>

For such shows, apps could choose to display something like "Next episode: Wed, 03 Jan, 2024" instead of "On hiatus".