There seems to be some confusion about what belongs where in an RSS feed. I’ve discussed various pieces of the RSS technology in different articles, but this article is meant to put everything you need to know in one place.
The very latest RSS specification, what it consists of, what is “officially” optional, etc, can be found at RSS Advisory Board [1], which as of this writing was version 2.0.11 published March 30, 2009. Some people use the information about RSS at Harvard Law, but the information there is old as of this writing.
I don’t intend to review the file specification itself, but more that content and usage as it pertains to Audio Distribution for Broadcast. The examples and discussion that follow is from the perspective of the Audio Producer or Distributor, and as such assumes the published content is an audio file with associated information, produced as a series of some periodic time frame, which for broadcasting is usually not longer than weekly, but could be multiple times in a day.
There are two basic sections in the specification, the CHANNEL and the ITEM. An ITEM is a child of a CHANNEL. Every RSS feed will have at least one CHANNEL, and every CHANNEL will have at least one ITEM (otherwise, what’s the point?). The CHANNEL describes the grouping of the items, that being what the series is about.. This description, once defined, would never change unless a major change to the channels focus was to occur.
Let’s say a producer creates a weekly series about the “sound of light bulbs”. Here’s an example of the first three weeks in a weekly series:
| ITEM | |
| Title: | Incandescents in Winter |
| Description: | The sound of incandescent light bulbs under 200 watts in the winter months. |
| ITEM | |
| Title: | Incandescents in Summer |
| Description: | The sound of incandescent light bulbs under 200 watts in the summer months. |
| ITEM | |
| Title: | Superbright LEDs |
| Description: | Do super bright LEDs make any detectable sounds? Our scientists reveal the results of their experiments. |
And the description of the CHANNEL would be something like:
| CHANNEL | |
| Title: | Sound of Light Bulbs |
| Description: | Each week our scientists and investigators bring you samples of the various sound made by ordinary, consumer available light bulbs and light bulb replacements. |
| Link: | lrh.net/soundoflights |
This CHANNEL description would remain static, providing a quick summary about the general topic, allowing potential broadcasters to find it and decide to use it. The description MIGHT change in the future, if perhaps the focus changed off of “consumer available” to “generally available”, a wider or narrower focus.
Each line in the above CHANNEL table is called an ELEMENT. The three elements shown are required for every channel, and all other elements are considered optional. There are several more elements that can be used to describe the channel, and all of them are generally unchanging, except for two: pubDate and lastBuildDate. The lastBuildDate element is updated whenever any of the content of the channel has changed, which for our purposes means that a new ITEM was added, or an old one removed or updated. The pubDate element would be the most recent pubDate of an ITEM (if pubDates are being used), but not a future date. ITEMS can have a future pubDate which would indicate the content is not yet ready for broadcast. (It can be nice to have something ahead of time and be ready to broadcast on or after the pubDate.)
One of the elements of CHANNEL is ITEM, which is a entry with the content of the channel, in others words a story or a podcast. In our audio distribution usage, ITEM is always present with at least one occurrence, though multiple are allowed. An ITEM has several elements, all of them optional, but to effectively publish audio for broadcast, the following elements are required: TITLE, DESCRIPTION and ENCLOSURE. It is also strongly recommended to include PUBDATE because it allows broadcasters to know the freshness of an audio story.
The ENCLOSURE element is an URL (link) to a downloadable audio file. It should be downloadable without any special requirements, except for maybe a referrer, which would be the URL of the original RSS feed. No passwords should be required, nor any other special parameters, the PODgrabber would like not have any of that information. (Protection/restriction should be handled as a parameter on the RSS feed URL.) I’ve seen a case where a USER-AGENT meta-tag is expected, but I don’t recommend it.
RSS Feeds need to have a way to uniquely identify each story/podcast. There are two elements which can be used for this purpose, TITLE and GUID. Whichever is used, it must uniquely identify that version or release of the story, and change whenever the story is modified, corrected, changed or being offered as an encore..
RSS Feed user programs will likely use the TITLE element of an ITEM to determine if the content has already been received, but some will use the GUID.
Whichever “uniqueness” element you are using, you need to insure it is unique across all your publication sites, and specific to the entry. Different RSS feed files from different sites should not have a different TITLE or GUID elements for the same audio clip.
For example, an audio story “Labor in the Factory” could be the original publication. If an error is found an hour after publishing, and the item is corrected and republished, the name must be changed in case PODGrabbers have already grabbed the bad one. The new title could be “Labor in the Factory-correction”. Further corrections and publishings should be numbered as in “Labor in the Factory-correction#2”. An encore re-publishing, say months later, also needs a unique name, especially when the original publication is still listed in the RSS feed channel, and could be something like “Labor in the Factory-encore for May2016”.
In reality, if a weekly or daily series is named “Today In Science”, the title should include at least a partial date, as in “Today In Science for April 22”, including the year might be even better. When a series has the same exact name for every story, it becomes difficult for a broadcast to know which day or week ‘s story the cut is, especially when there are several on hand.
Changing the name when publishing corrections of encores is critical from the Broadcasters point of view, when using an automated PODGrabber. It needs to know the cut is newly queued so it will be placed into the Broadcasters schedule. Without the title change, the PODGrabber will not download the audio, and it will appear missing for that week or day. As mentioned, this is especially important when the feed is listing all the available audio stories.
And while we’re on that, an RSS feed should return all the available audio stories in most cases. Any feed that contains evergreen content should return a list of everything available. Broadcasters like to see many weeks/months of stories for a new series they want to include in their broadcast, and you want them to get them. The PODGrabber should be able to get everything and have it available to schedule.
In the case of “not so evergreen” stories, a little discretion is needed. A daily news story could probably only appear in the feed until the next daily news story is published, and the same could be said for a weekly news story, it should be available until the next week is published. If the series is timely but not timeless, it may be better to leave stories in the feed for a longer time, 2-3 months for a weekly publication. A broadcaster could then start using your series starting a few weeks back, which is great for listeners that missed it the first time. Note that there is no problem leaving ALL the items in the feed. With unique naming, and maybe pubDates, any broadcaster will only want the latest for timely stories, and will adjust the PODgrabber to start with “today’s” entry. Having everything still listed allows a broadcaster to go manually retrieve an older story if needed.
When you put yourself in the shoes of the broadcaster who wants to get your podcasts in a timely, organized and useful way, you’ll see that consistency is important, and understanding the process and data flow is critical.