So after my two posts on XSPF and some public discussion in the comments, I took the conversation with Lucas offline in hopes of getting a better understanding about the thought process that went into the spec. Unfortunately, Lucas has reacted as if I called his baby ugly and we got nowhere. Needless to say, I still believe that XSPF is completely redundant because it is nearly semantically identical to RSS.

To demonstrate, here’s a list of every playlist element from the XSPF version 1 spec and how it maps to channel elements from RSS version 2.

• /playlist/title -> /rss/channel/title
• /playlist/creator -> /rss/channel/managingEditor
• /playlist/annotation -> /rss/channel/description
• /playlist/info -> /rss/channel/link
• /playlist/image -> /rss/channel/image
• /playlist/date -> /rss/channel/pubDate
• /playlist/license -> /rss/channel/copyright
• /playlist/location -> create custom element
• /playlist/identifier -> create custom element
• /playlist/attribution -> create custom element
• /playlist/link -> No need in RSS
• /playlist/meta -> No need in RSS
• /playlist/extension -> No need in RSS

That’s a pretty close match. There are a few things we need extensions for to represent in RSS, but nothing major. BTW, from what I can tell, the reason XSPF has link, meta and extension elements is for extensibility purposes. RSS supports an extremely flexible extensibility model already, so there’s no need for the XSPF specific extensibility elements.

Here’s the mapping of track elements in XSPF to item elements in RSS.

• /playlist/trackList/track/location -> /rss/channel/item/enclosure
• /playlist/trackList/track/identifier -> /rss/channel/item/guid
• /playlist/trackList/track/title -> /rss/channel/item/title
• /playlist/trackList/track/creator -> /rss/channel/item/author
• /playlist/trackList/track/annotation -> /rss/channel/item/description
• /playlist/trackList/track/info -> /rss/channel/item/link
• /playlist/trackList/track/image -> create custom element
• /playlist/trackList/track/album -> create custom element
• /playlist/trackList/track/trackNum -> create custom element
• /playlist/trackList/track/duration -> create custom element
• /playlist/trackList/track/link -> No need in RSS
• /playlist/trackList/track/meta -> No need in RSS
• /playlist/trackList/track/extension -> No need in RSS

Again, pretty close match. As you can see, the majority of the XSPF elements have a direct equivalent on the RSS side. Certainly, the most important elements (playlist title, list of tracks, track location) have a direct equivalent. For the remaining XSPF elements that have no RSS equivalent, you could easily extend RSS to support those elements. In fact, you can easily encode the sample playlists from the XSPF spec in RSS without any extensions whatsoever:

<rss version="2.0">
  <channel>
    <title>My Playlist</title>
    <link>http://devhawk.net/playlists/myplaylist</link>
    <description>Here's my playlist</description>
    <item>
        <enclosure length="..." type="audio/mpeg" url="http://example.com/song_1.mp3"/>
    </item>
    <item>
        <enclosure length="..." type="audio/mpeg" url="http://example.com/song_2.mp3"/>
    </item>
    <item>
        <enclosure length="..." type="audio/mpeg" url=http://example.com/song_3.mp3/>
    </item>
  </channel>
</rss>

So you may be wondering why I’m taken so much time on this topic. Frankly, I don’t really care one way or the other about XPSF. As I wrote in my last post, I’m just trying to understand this space better. The reason this specific example interests me is because it is so obviously a duplication of effort with little discernable upside. And furthermore it’s being touted by Marc Canter who I know is all about open standards. Why is the XSPF open standard better than the RSS open standard? Or Atom for that matter? Atom’s creators explicitly describe Atom’s syndication format as “an XML-based Web content and metadata syndication format”. How is XSPF different from that, other than narrowing the scope down to multimedia content and metadata? What’s the value of the narrow scope specification when the wider scope specification is so widely adopted?

As you might guess, my opinion is that the narrow scope specification has no value. I assume that’s why Lucas responded so negatively. But the root issue doesn’t go away. XSPF and RSS both describe lists of stuff. XSPF is specific to lists of media while RSS is typically used for lists of weblog entries but can be used for lists of anything – including media. What’s a podcast feed but an RSS encoded playlist?

The problem is that by introduced yet another syntax for basically the same semantics, XSPF can’t take advantage of the existing tools and platforms around RSS. And I’m not just talking about the Windows Feed API, I’m talking about every implementation of RSS on every website and in every news reader or podcatcher around. Why wouldn’t you want to ride that wave?

A while ago, I made a sign for my door that reads “Architecture Help 5¢” (in homage to Lucy’s psychiatry stand in Peanuts of course.) I get the occasional comment on it, so I decided to experiment and make a t-shirt out of it. These days, making your own t-shirt is cake with online services such as CafePress, T-Shirt Junky and Zazzle. I like Zazzle’s pricing structure the best – they have a flat fee and pay you a royalty on sales. CafePress has a baseline fee and you can then charge whatever you want on top of that. I didn’t want to be mucking around with pricing, so I went with Zazzle. Also, Zazzle has more choices and options for t-shirts than CafePress did.

My Zazzle gallery is named DevHawk Designs. So far, I have two products – the Architecture Help 5¢ shirt in black and in white, though Zazzle allows you to customize the shirt so you can get it on pink or navy blue if you really want it. I made it with Expression Graphic Designer, though it’s such a simple design I’m sure I didn’t really exercise its capabilities at all.

Other than me, I’m not sure who’s going to buy one of these. Believe me, I have no vision of being the next ThinkGeek. But let me know what you think, good or bad.

Lucas Gonze left me a comment indicating they had in fact investigated using RSS for XSFP instead of starting from scratch. Good to know they considered the possibility. Unfortunately, it looks like they were using RSS 1.0 so it has all the extra RDF stuff which really hasn’t caught on. The document doesn’t really go into the reasons they chose to go a different way, though Lucas does say the following:

RSS didn’t make sense for a lot of reasons. We were paving cowpaths, and RSS for playlists was very much not a cowpath. Playlists are about sequence, while RSS has no concept of sequence except reverse chronological order. We needed abstractions to deal with the fact that music and movies frequently don’t have URLs, and RSS didn’t have them. If not starting from scratch was critical, HTML preceded RSS and would be the default to work from.

I’m not sure I get Lucas’ point about sequence. Both RSS and XSFP have sequence. Sure, RSS is typically describing web site content, thus it’s a reverse chronological order. But the RSS spec doesn’t mandate and specific meaning to the items in the feed. In fact, the items typically have a pubDate element making the order in the feed somewhat irrelevant. According to the spec, XSFP uses the order of the tracks in the file as the implicit playback order. Why that wouldn’t work with RSS is a mystery to me.

As for the “needed abstractions” missing from RSS, I’d be curious to know what those are and why they couldn’t be added via RSS extensions.

Lucas, please don’t take these comments as criticisms. I’m new in this space and I’m trying to get my head around stuff. Furthermore, if the success of RSS proves anything, it’s that number of users matters a lot more than the perceived technical merit of a given approach.

Marc Canter seems pretty excited that Songbird is going to support XSPF. While Marc has written about it many times, I had no idea what it was. It’s the XML Shareable Playlist Format (pronounced “spiff”). It’s designed to be simple and open and built on XML. Typically, that’s coolness but while reading the spec, I had a strong sense of deja-vu. XSPF defines a list of songs for a playlist, much the same way that RSS defines a list of blog entries.

So that begs the question, why didn’t XSPF just use RSS instead of starting from scratch? RSS is simple, open, built on XML and is massively popular? Remember when Adam Bosworth that pointed out that RSS and Atom are “both support a base schema that provides a model for sets”. I’m all for a simple, open and extensible playlist format, but I’m not excited that XSPF has gone of an reinvented the concept of “list” in order to do it.

Hot on the heels of my post about the AJAX toolkit spectrum comes news that Yahoo! has released their own AJAX toolkit as well as a very cool web page design pattern catalog.

Some non-surprises:

• The Yahoo! toolkit has it’s own animation library, it’s own drag and drop library and it’s own XmlHttpRequest wrapper, just like other libraries like Dojo and prototype.
• The Yahoo! UI Controls depend on Yahoo’s Core Utilities. The libraries are modular, but not polymorphic with other these libraries.
• The code was released under an open source license (BSD).

All these different implementations of the same core set of capabilities at best means learning lots of ways of doing the same thing and at worst means incompatibility between components from different libraries.

BTW, last week I wrote that using a text-based high-level scripting language like Javascript in the browser “encourages business models where the in-browser code has little if any value.” This release from Yahoo! supports that point. While their mapping component is subject a strict Terms of Use, their UI components were released with a liberal open source licence. I doubt that’s a coincidence.