Proposal - <podcast:state> tag for granular state info
daveajones opened this issue · 8 comments
One thing that is sorely needed for aggregators, apps, stats, etc. is a way to know what "state" a podcast is in. I mean things like "trial" (when a podcast is hosted under a free trial period), "subscription" (when the enclosures are behind a paywall), "hiatus" (when the show is on pause for a few weeks or months but will return), "delayed" (when a new episode is coming but missed it's regular time slot), "complete" (when a show will never publish another episode).
The only tag that fits this type of role currently is <itunes:complete>, but its not granular enough to convey other important information about the podcast. In many cases, podcasters resort to shoehorning this type of communication into the shownotes or publishing a filler episode explaining the situation. This tag would allow for a more programmatic approach, so that apps and platforms can communicate to the listener
State
<podcast:state>
This tag is used to convey important information about the current state of this podcast that would be helpful for the world to know, such as whether it's on hiatus, if it's a free trial period account or maybe it's been delayed from it's normal schedule and will publish again soon.
Parent
<channel>
Count
Single
Node value
The node value is a comma separated list of these possible pre-defined values:
- trial: This podcast is hosted under a limited, "free trial" period at it's hosting company.
- complete: This podcast will never post another episode.
- subscription: This podcast has enclosures that won't be delivered without a subscription token.
- delayed: This podcast has missed it's regular publish schedule but will publish again soon.
- hiatus: This podcast is on an extended break from publishing but will resume at some time in the future.
Examples
<podcast:state>complete, subscription</podcast:state><podcast:state>trial</podcast:state><podcast:state>hiatus</podcaststate>Grammatically, why would we want "state" instead of "status"?
Are you sure we should be comma-plus-space-separating multiple values instead of using multiple tags?
If we're already accepting the ability to assign multiple states, I wonder if this should be combined with a frequency tag. So a podcast is daily/weekly/monthly when it's active, and having both "weekly" and "hiatus" could communicate that it will be weekly when it returns from hiatus or that it was weekly before the hiatus.
Grammatically, why would we want "state" instead of "status"?
Names don't matter to me. Feel free to name it and I'll go with whatever you think. State and status neither one seem very satisfying.
Are you sure we should be comma-plus-space-separating multiple values instead of using multiple tags?
You're probably right. Multiple tags would be better for parsing.
I wonder if this should be combined with a frequency tag.
I'm really not a fan of frequency tags since they are so squishy and don't really translate into real life very well.
In that case, I think "status" would communicate better. But I'm not sure "subscription" even belongs in here, because a subscription would probably be indicated by the use of its own relevant tags (when we get those sorted out).
And regardless of the squishiness of frequency, I think that can be its own separate tag. After all, "weekly" isn't a description of status anyway.
Maybe it should be called podcast:attribute since it's really just meant to specify some important things that are true about a podcast?
I'm with Daniel on this. Trial & subscription are orthogonal to complete / delayed / hiatus / (no value), and we shouldn't be mixing up the two concepts with the same tag. As for "delayed" I'm not even sure that's really necessary in the first place, especially without any way of specifying (yet) a frequency that episodes are released.
Hi
Is this tag now complete? Is anyone testing this as a host? I'd love to include this in my new app.
- Trial sounds interesting for analysis reasons, but currently, it’s unclear why hosts might be interested in adopting it. (Especially if it causes their new feeds to be deprioritized in any way.)
- Shouldn’t the subscription attribute be part of a more comprehensive spec for premium content?
- It’s my hope that my updateFrequency proposal addresses the need for complete/delayed/hiatus attributes.
Perhaps I'll pull this proposal for now until there is a better way to do each of the intended things. Thanks for the feedback all.