intertwingly

Steve Harris - 2nd best bassist in the world !!

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...

It’s not really gone. It is just temporarily unavailable or simply nonexistent.

Anne,  you crack me up ;)

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:

-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.

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!

One 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.

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.

Steve: both changes (support for itunes:image/@href and channel/itunes:keywords) are both online.

It now seems that FeedValidator has been updated for the latest iTunes 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:

<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.

Sam: 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.

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.

My 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.

[link]...

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]

Trackback from Sam Ruby