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.
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...
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.
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!
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.
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)...
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.
cymago: 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:
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?
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...
[more]