Apple has released their PodCast Specifications. I note three places where the specifications deviate from their sample, in one case, significantly so.
<itunes:explicit>no</itunes:explicit>
<itunes:duration>7:04</itunes:duration>
<itunes:link rel="image"
type="video/jpeg"
href="http://www.itunes.com/podcasts/everything/AllAboutEverything.jpg">All
About Everything</itunes:link>
Other thoughts:
itunes:category
, validation can be a significant value
add here.I ran into the same issues this morning. And now, when I try to submit my feed, I get “We are currently experiencing technical difficulties. Please try again later.”
Oh, well. Hopefully they get it all worked out. Still not sure how they want images included, though.
Here’s another problem:
"<itunes:block>
This tag is used to block a podcast or an episode within a podcast from being posted to iTunes. Only use this tag when you want a podcast or an episode to appear within the iTunes podcast directory."
The first and second sentences are contradictory, aren’t they? Shouldn’t the second say "...when you DON’T want..."?
And what should the value of this element be? Should it just be empty (eg. <itunes:block /> or <itunes:block></itunes:block>)--ie., does it’s mere presence indicate that the item should be blocked (that' how I read it), or should it have a value?
And finally, I assume this can appear either at the channel or item level to block the entire feed or just one item, right? Being explicit about that wouldn’t hurt.
Other questions worth asking:
Why itunes:category? Why not reuse the category element in RSS
I 'spose they could have specified their own taxonomy domain. And warned users that all other taxonomies/plain-text categories would be ignored.
Why itunes:summary?
Cuz, unlike the notoriously under-specified <description> element, they can say:
“Limited to 4000 characters or less, plain text, no HTML”
Why itunes:author?
Cuz, notoriously, the content of the item-level <author> element is an email address.
Why itunes:keywords? Why not reuse dc:subject?
Fair enough, though it is yet another namespace (funky, y’know...)
Why itunes:owner? Why not reuse channel/webMaster?
“Email address for person responsible for technical issues relating to channel.”
Not the same thing at all...
Why itunes:image? Why not reuse channel/image?
"This artwork can be larger than the maximum allowed by RSS. Details on the size recommendations are in the
section below."
Why are they redefining the content model of copyright?
?
Word on the street is that <itunes:image> doesn’t work, and <itunes:link href=""> does.
Most amusing (in the sense of "I laughed so hard I spit bitten-tongue blood across the room") find, while looking at their prominently featured partners' feeds for clues: Disney has replaced the core /channel/image/url with <itunes:link>(their image url)</itunes:link>
Well, back to the RSS 1.0 RSS 0.91 module, which defines <rss091:webmaster> for sideways compatibility with <webMaster>. If Mark ever does find that hobby, I sure hope he tells me what it is, and how to get started in it.
I wonder if it works anyway (for things other than the image), implying qname-matching regex parsing?
Yes, the Disney namespace (PodCast instead of Podcast) works. But it’s not based on qname, and it’s not based on regular expressions. From my tests so far ( [link] ):
By “works”, I mean it downloads and parses the feed, displays it in the local Podcasts subscriptions list, and downloads my sample MP3.
By “does not work at all”, I mean it displays nothing from the feed, only the URL and a “!” icon that, when selected, displays an alert “URL does not seem to be a valid Podcast URL.”
So it appears that iTunes uses a real, draconian, namespace-aware XML parser... except that namespaces are case-insensitive.
I pass along this information without further comment or judgement.
It appears that iTunes 4.9 doesn’t EVER respect the charset parameter in the HTTP Content-type header. Test cases:
[link] contains:
<?xml version='1.0' encoding='iso-8859-1'?>
If this were removed, and if iTunes 4.9 ignored the charset parameter, then the feed would not be considered well formed.
If this were removed, and if iTunes 4.9 ignored the charset parameter, then the feed would not be considered well formed.
You are correct, that feed was not actually testing what I thought it was testing. (The other two appear to be accurate tests.) I’ve corrected the feed to match my prose description (HTTP declares “windows-1252”, XML has no encoding), and iTunes now exhibits the behavior you predicted: it does not look at the HTTP charset parameter at all, and since the XML body has no encoding information, it fails to parse the feed at all.
The itunes:image tag has been fixed and now works.
The format is as follows:
<itunes:image href="http://example.com/your-podcast-logo.jpg" />
There are also updated docs that they say should be coming out shortly.
I just spent 3 days trying to find one parser in this world that would show itunes channel image.
Seems I am sol. < itunes:image href=" seems unparsable?
Web Standards????