Apple have released iTunes 4.9 with support for downloading podcasts. At the same time, they've released a set of extensions for RSS that affects how podcasts will show up in the iTunes Music Store.
The specification can be downloaded as a PDF from Apple's site. (It annoys me how Apple don't quite get this web thing, despite being cool in other respects.)
Here's a quick review of the elements they've specified.
First up, the namespace, http://www.itunes.com/DTDs/Podcast-1.0.dtd. Apparently DTD as a namespace, containing a version number in the name. Almost always a bad idea. Versioning and namespaces are a complex mix, and limiting future flexibility by changing the namespace with each revision can be a bad idea. Try resolving that URI, and you get redirected to an HTML page. Verdict: poor.
Let's look at something helpful now. The itunes:duration element is useful, carrying some much-needed extra metadata about audio content. Verdict: good.
Next up, there's a bunch of replicated Dublin Core type metadata, all in the iTunes namespace: owner, name, email, author, keywords. It would have been nice if existing conventions for dc:publisher, dc:creator etc. could have been re-used. That way RSS feeds won't get cluttered with multiple redundant elements. Nevertheless, I can see why iTunes might want all this stuff completely disambiguated. They don't imagine finding RSS in the wild and adding it to the iTunes store, instead they expect people to create RSS with the express purpose of lodging it with iTunes. Verdict: so-so.
There's an itunes:image element, for specifying imagery for the iTunes store. Reuse is less likely in this case, so a dedicated element makes total sense. Verdict: good.
A selection of elements cover textual description. We all know about RSS's description, but iTunes adds itunes:summary and itunes:subtitle. Both of these elements are mandated to be plain text. In most cases, it looks like summary should be the same as description. The egregious practice of including escaped HTML in description--which was meant to be a plaintext field--has meant this situation is just about unavoidable. I do worry that with title, description, summary and subtitle this is all getting rather too complex. Verdict: okay.
Categorisation within the iTunes store is handled by the itunes:category element. You have to see this markup to believe it:
<itunes:category text="Technology"> <itunes:category text="Gadgets" /> </itunes:category>
Add to that a prose restriction that categories can only be nested to two levels and I'm left scratching my head. It also stands out as just about the only attribute-carried text content within RSS. Verdict: nuts.
The remaining elements are used to control content restrictions within iTunes. The itunes:explicit element is meant to be included if your content is "explicit". Okay... And itunes:block can be used to block a podcast from appearing in the iTunes store. These elements seem vague, underspecified and certainly open to abuse. Verdict: poor.
Some miscellaneous observations. iTunes wants RSS feeds in UTF-8. Verdict: good. Aside from itunes:summary, "all fields will be truncated to 255 characters". Verdict: daft.
I'd like to provide more detail, but on clicking the "Learn more" link on Apple's podcasting page results in a blank page on my Firefox, with an error "itmss is not a registered protocol". Verdict: gob-smackingly ignorant.
What could have been a useful and reusable addition to the world of RSS is really rendered only fit for the single use of adding content into Apple's own iTunes store. Apple prove they know how to be cool, but they've got no idea about making friends on the web.
From the point of view of XML and the web, iTunes RSS extensions are somewhat disappointing. From a professional point of view, I'd say this looks rather embarrassing: Apple clearly don't have enough people who really understand XML.