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.
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.
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
Each item has its guid. I don’t see why the last one fails?
cymago: 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.
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...
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...