<p><a href=”http://archive.scripting.com/2005/06/20#When:8:42:37PM”>Dave Winer</a> is <a href=”http://www.opml.org/spec”>OPML</a>’s biggest cheerleader, for obvious reasons. He mentions that <a href=”http://www.steve-lacey.com/blogarchives/2005/06/podcast_shownot.shtml”>Steve Lacey thinks podcast shownotes should be RSS</a>. I think Dave’s right in that Steve’s approach is wrong, but I think Steve’s right that <a href=”http://blogs.law.harvard.edu/tech/rss”>RSS</a> is the answer, not OPML.</p>

<p>Here’s my take on it: suppose each podcast is treated as its own RSS <channel>. Suppose each “segment” within the podcast that there are notes for is treated as its own RSS <item>. Suppose we adopt the convention for audio URLs that named anchors of the form “[[hh:]mm:]ss[.xxx]“, or hours, minutes, seconds, and milliseconds from the start of the audio. (I’m not sure I really like this format. Perhaps a simple integer number of milliseconds would be better.) So, an example RSS for a fictitious podcast might look like:</p>

<xmp style=”overflow: auto;”>
<rss version=”2.0″>
<channel>
<title>Some Podcast: June 21, 2005</title>
<link>http://www.example.com/link-to-this.xml</link>
<description>
Some descriptive copy about this podcast in general.
</description>
<item>
<description>Notes for this segment of the podcast, starting at 0 sec.</description>
<enclosure url=”http://www.example.com/path-to-podcast.mp3#0″ length=”8675309″ type=”audio/mpeg”/>
</item>
<item>
<description>Another segment, starting 1 minute, 28 seconds in.</description>
<enclosure url=”http://www.example.com/path-to-podcast.mp3#1:28″ length=”8675309″ type=”audio/mpeg”/>
</item>
</channel>
</rss>
</xmp>

<p>This approach would require no change to the RSS specification, unlike Steve’s approach; it would just require applications that process RSS to understand the URL correctly, and those that haven’t been updated will degrade gracefully if they parse URL’s correctly and ignore the anchor portion. One downside of this approach is only being able to specify the starting offset and not the length of the segment, though.</p>

<p>If we <b>are</b> going to change the specification in order to introduce this capability, my preferred solution would be to extend the <enclosure> tag to introduce two new attributes: startOffset, endOffset. For simplicity, these would be integer values in number of milliseconds as offsets into the audio stream. Again, this is simple and straightforward, and backwards-compatible if older applications degrade gracefully and ignore the attributes they don’t recognize.</p>

<p>Hopefully, someone out there will see this rambling and give it some thought.</p>

This entry was posted by Dossy Shiobara on Tuesday, June 21st, 2005 at 10:13 am and is filed under Geeking out. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.