A Shownotes Alternative Suggested
Dossy suggests that my approach to shownotes as RSS is wrong. I have to respectfully disagree with his arguments.
He claims that my suggestion would require a change in the RSS specification. This is not true. My approach is an extension via the use of a namespace. This is a subtle distinction, but an important one.
Current podcatching clients will continue to work fine and new ones could be enhanced to look for the new element that describes the location of the shownotes rss file and then parse that.
Even further, Dossy initially says that his alternative requires no changes to the RSS spec, and then goes on to define a new semantic to be applied to urls in the enclosure element and suggests extensions to the enclosure element.
I'm glad someone is joining the conversation though...
Next up, I believe that Dave Winer may actually be right and suggest an alternative using OPML that may be the, ahem, winner.
Categories:
0 TrackBacks
Listed below are links to blogs that reference this entry: A Shownotes Alternative Suggested.
TrackBack URL for this entry: http://www.steve-lacey.com/cgi-bin/mt/mt-bar.cgi/460
3 Comments
Leave a comment
About Me
Steve Lacey, software developer at Google, British, married to the lurvely Nabila, dad to the wonderful Julian and Jasmine. Living in Kirkland (near Seattle), WA.
steve@steve-lacey.com
+1 (425) 214-4716
Syndication
Popular Posts
Recent Entries
Recent Podcasts
- A Brit Abroad - April 16, 2006
- G'Day World!
- A Brit Abroad - November 26, 2005
- A Brit Abroad - October 13, 2005
- A Brit Abroad - September 20, 2005
- The First Britcaster Podcaster
- BritPack number 4 is alive!
- A Brit Abroad - August 15, 2005
- A Brit Abroad - July 13, 2005
- The BritPack #2 - The Very Best Of British Podcasting
- Subscribe...
Monthly Archives
- January 2010 (1)
- December 2009 (1)
- November 2009 (2)
- October 2009 (2)
- September 2009 (1)
- August 2009 (1)
- July 2009 (3)
- June 2009 (2)
- May 2009 (2)
- March 2009 (4)
- January 2009 (3)
- December 2008 (5)
- November 2008 (2)
- October 2008 (2)
- September 2008 (6)
- August 2008 (3)
- July 2008 (6)
- June 2008 (4)
- May 2008 (12)
- April 2008 (16)
- March 2008 (4)
- February 2008 (7)
- January 2008 (11)
- December 2007 (8)
- November 2007 (15)
- October 2007 (8)
- September 2007 (8)
- August 2007 (19)
- July 2007 (9)
- June 2007 (10)
- May 2007 (13)
- April 2007 (11)
- March 2007 (13)
- February 2007 (13)
- January 2007 (19)
- December 2006 (18)
- November 2006 (15)
- October 2006 (15)
- September 2006 (10)
- August 2006 (18)
- July 2006 (24)
- June 2006 (23)
- May 2006 (21)
- April 2006 (23)
- March 2006 (18)
- February 2006 (25)
- January 2006 (36)
- December 2005 (37)
- November 2005 (34)
- October 2005 (37)
- September 2005 (39)
- August 2005 (28)
- July 2005 (33)
- June 2005 (42)
- May 2005 (22)
- April 2005 (40)
- March 2005 (31)
- February 2005 (19)
- January 2005 (25)
- December 2004 (16)
- November 2004 (18)
- October 2004 (26)
- September 2004 (20)
- August 2004 (20)
- July 2004 (23)
- May 2003 (1)
- March 2003 (1)
- February 2003 (2)
- January 2003 (2)
- December 2002 (4)
- September 2002 (4)
- August 2002 (3)
- February 2002 (1)
- January 2002 (9)
- November 2001 (1)
- October 2001 (14)
Categories
Search
About this Entry
This page contains a single entry by Steve published on June 21, 2005 10:32 AM.
Podcast Shownotes As RSS was the previous entry in this blog.
Podcast Shownotes As OPML is the next entry in this blog.
Find recent content on the main index or look in the archives to find all content.
Statsorama
- 1044 posts
- 1327 comments
The use of the anchor portion of the URL doesn't change the RSS specification. Addition of the two attributes to the enclosure element does.
I think the enclosure element should be used to reference the shownotes metadata (whether it be RSS or OPML or whatever), too. So, an entry will have one enclosure element that points to the audio URL, and another one that points to the shownotes metadata URL.
I don't get the "subtle" difference that makes introducing new elements in a namespace "the right solution" -- could you explain a bit more?
I guess my bias is to keep related information together. Information that's specifically relevant to an element should be an attribute of the element, not a new element in a namespace.
It's also why I'm not a big fan of OPML, because of its use of the text attribute on the outline element, instead of making the outline text the node value. I think Eric Meyer's S5 is a better example of how markup should be structured for outlines.
Thanks for responding,
-- Dossy
By the way, your TypeKey sign-in link (or something else) is broken. Clicking on it sends me to a page that tells me:
"The validation failed."
Perhaps this is because I've already signed in via TypeKey to someone else's blog in this browser session and there's some cookie nonsense going on. Go TypeKey. *sigh*
On the namespace thing. If the client of the file parses the file as per the rss spec, it will get everything it needs, the elements it's expecting to see are there and the semantics of the elements have not changed.
Now, if you want to add new information - like the creator via Dublin Core's <dc:creator> you can do that. If the client understands that namespace it gets new information, but the core specification has not changed.
Regarding the anchor on the url - in order to parse that, the client needs to expect it and know how to decode it. By putting this in the url attribute of the enclosure element you've broken clients, because AFAIK that's not how the enclosure element is defined - are anchors on media files defined anywhere?
As for the typekey thing - yeah. I don't even use it. It must go...
Cheers,
Steve