Podcasting Specifications Update
Steve Harris: A much more clear, consistent and readable specification for the iTunes RSS Specification is now available, dated 7/7/2005: [link]
The previous specification appears to be gone. (Google Cache in HTML format)
- block still is underspecified and without an example.
- category no longer has an explicit list of permissible categories and sub-categories?
- duration is explicit about how it can be subsetted. Excellent.
- values for explicit are now lowercase. I’m going to continue to presume that case is not significant.
- keywords is unchanged, and did not have any issues before.
- image apparently has a href attribute. Can it be relative, or must it be absolute? No examples. For now, I’m going to assume absolute.
- owner doesn’t indicate which nested elements are required. Previously, email was required. Name is now limited to 255 characters.
- subtitle is unchanged, and did not have any issues before.
- summary is unchanged, and did not have any issues before.
Additionally: guid is now recommended for any entries which contain a podcast (excellent).
enclosure is limited to five supported extensions. Apparently, file extensions are used instead of the type attribute. The latter would have seemed to be more general purpose.
The wording recommending utf-8 seems to be stronger now.
I’ll try to get these changes into the FeedValidator by tomorrow.
Sam Ruby: Podcasting Specifications Update
kayodeok : Sam Ruby: Podcasting Specifications Update - A much more clear, consistent and readable specification for the iTunes RSS Specification is now available, dated 7/7/2005...Excerpt from HotLinks - Level 1 at
I don’t think it’s correct that the <itunes:image> has an “url” attribute, but an URL in a “href” attribute.
The spec says:
This tag specifies the artwork for your podcast. Put the url to the image in the href attribute.
And in the example:
<itunes:image href="http://example.com/podcasts/everything/AllAboutEverything.jpg" />
-Steve
(Not the second-best bass player in the world)
Steve: good catch. Presumably, this was picked for consistency with the enclosure tag (Not!). In any case, I’ve made the fix in the text above, and the commit to the FeedValidator is working its way towards deployment.
Posted by Sam Ruby at
Sam, that’s excellent, I really appreciate the speed of development here.
There does seem to have been a random “pick an attribute name from the hat” thing going on with these iTunes tags.
FeedValidator is a vital tool for me and what I’m doing (desktop RSS creation app) and your posts on this blog have been extremely useful in untangling this mess. Thank you!
Posted by Steve Harris atOne other thing I noticed is that the keywords tag can now be applied to both the channel and items. In the old spec, it was just items.
Posted by Steve Harris at
I’m assuming that the iTunes application has not been updated, and that this spec is an attempt to document the application’s current behavior. Some cursory notes:
- The spec is now available in HTML. It even validates. Hooray! Welcome to the web. (I suppose it would be too much to ask to use real headers instead of [p class="p1"], [p class="p2"], [p class="p3"].)
- The namespace still does not match the namespace that is actually used by the iTunes application.
- Despite their dire warnings, UTF-16 encoded feeds do appear to be properly parsed by iTunes. [test case] Which is good, since the XML spec requires it.
- itunes:image is referenced in the text, but not in the summary table that describes where elements are allowed.
- Filtering enclosures and images by file extension is brain-dead.
- The copyright element in their example now includes a copyright symbol. The first revision of the spec stated “You do not need to include the copyright symbol in the tag, it will automatically be displayed in iTunes.”
- Despite listing invalid dates in their list of common mistakes, iTunes accepts and displays many types of non-RFC-2822-compliant dates, as previously reported.
All in all, Apple’s latest revision is an excellent blog post. It’s a shame it’s being passed off as a spec.
Posted by Mark atSteve: both changes (support for itunes:image/@href and channel/itunes:keywords) are both online.
Posted by Sam Ruby at
iTunes Spec & FeedValidator Update
It now seems that FeedValidator has been updated for the latest iTunes spec......Excerpt from Reinvented Blog at
New iTunes RSS extension spec
A few days ago, Apple published a new version of their iTunes RSS extension spec. It’s better, but still considerably flawed. At least it’s in HTML this time. (via Reinvented, via Intertwingly)...Excerpt from Matthew Gifford at
Hello, I am working on a podcast plugin for DotClear and I don’t understand some aspects of the new document.
Note than the “specification” term no longer appears in the new html document. Let’s assume that it describes how both the iTunes 4.9 and the directory manager for podcasts in the Music store works.
Let’s assume also that the Sample RSS 2.0 feed is a real working one (when we have real values for fields).
Seems that this new feed does not validate in Feed validator. The <description> is required by the validator.
Why they use the example.com location instead of the www.itunes.com recommended one at the top of document, is the Podcast-1.0.dtd the same in both location?
There are several ending possibilities for the itunes:category tag
</itunes:category> /> >
and without a separating blank character for the last two ones. There is one in the itunes:image tag. Is there a special meaning (category versus subcategory)?
How to handle that? My current answer is to generate only the </itunes:category> ending tag.
Do I have to generate these types for each extension?
audio/x-m4a for m4a
audio/mpeg for mp3
video/quicktime for mov
audio/mp4 for mp4
application/pdf for pdf
Sorry for the bad english and the long post. Hope you can answer. Thanks.
Posted by cymago atcymago: the sample RSS 2.0 feed is buggy. We’ve offered to help. The namespace is wrong in the sample, the channel description is missing, and two of the categories are not closed properly.
Now, as to your questions, each of the following are equivalent:
<itunes:category text="Politics"/> <itunes:category text="Politics" /> <itunes:category text="Politics"></itunes:category>
and you appear to have the extension to mime type mappings correct.
Posted by Sam Ruby atSam: thanks. I think I have my answers now. I will follow the Feed validator. The Podcast checker 1.13 does not check the itunes:image tag.
Posted by cymago at
The following RSS 2.0 test feed
[link]
does not validate with the Feed validator:
line 320, column 52: guid values must not be duplicated within a feed
<guid isPermaLink="false"><![CDATA[demo.mp3]]></guid>
Each item has its guid. I don’t see why the last one fails?
Posted by cymago atcymago: the answer is because the item referencing the enclosure http://cvie.free.fr/blog/share/audio/demo.mp3 and the item referencing the enclosure http://cvie.free.fr/podcast/demo.mp3 have the same value specified for their corresponding guid value.
Why is that important? Well consider the processing model of the consumer. It reads your feed periodically. It then parses your feed into items. Some of these items it may have seen before, some may be new. How does it tell which is which? From the latest “spec” (which you rightly point out doesn’t call itself a spec, but at the moment, it is what we have):
When you add episodes to your feed, guids are compared in case sensitive fashion to determine which episodes are new.
What this means is that if you reuse a GUID in a different item, one of the two will not be seen as new. Instead, it may be seen as an update or a replacement for the other item.
Posted by Sam Ruby atMy documentation says: you have to handle yourself the GUID if you have 2 files with the same filename and modify it (it must be unique).
I am not following my own recommendations!
I will add a check to verify that there are no duplicate GUID when generating the RSS feed.
Thank again, you and the Feed validator are far more than useful.
Posted by cymago atAtom 1.0
As Tim Bray points out, Atom 1.0 is, essentially, finished. Draft 10 finally gives it its official namespace, which unambiguously identifies a feed that follows the final spec, rather than one of the many drafts. Sam is working through the huge...Excerpt from Kafsemo.org at
Undecipherable Specification Error Redux
Last June, I wrote about a some ambiguities in an Apple spec that were troubling me. More troubling than the ambiguities was the lack of an ability to have a conversation. So I decided to raise a flag. The technique worked. It took multiple ite... [more]Trackback from Sam Ruby at
Steve Harris - 2nd best bassist in the world !!
Posted by ericd at