I don’t know how I missed this before, but Tim Bray blogged about not inventing XML languages over a month ago. This comment is right on the money: “The value of a markup language is proportional approximately to the square of the number of different software implementations that can process it.” Conceptually, I agree with him – my primary argument against XSPF is that it has the same basic semantics as RSS, but RSS is much more widely used. But his list of the “big five” markup lanugages seems more like the “wannabe five”. How many different siftware implementations process any of the things on his list?

I’m not arguing the technical quality of these lanugages – frankly I’m not that familiar with any of them but Atom. But if you’re arguing the network effect, none of these formats Tim lists qualify. I’m sure he wants them to be popular, but wishing doesn’t make it so.

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?

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.

Last week, Dion wrote about the spectrum of AJAX tookits. He ended with a question, wondering which end of the spectrum will dominate? Will it be lightweight composable toolkits like prototype, script.aculo.us or Dojo? Or a more comprehensive toolkit like Atlas?

This came up in a chat I had w/ Jimmy Nilsson today. Well, not specifically about AJAX toolkits. Rather, we were talking about what he called technicalities vs. semantics:

I have noticed that there seems to be a focus first on the technicalities and then on the semantics. Take Indigo (or WCF) for example. There has been sooo much talk about its technical aspects, but very little talk about how to design for it. I’m pretty sure that when the technicalities have been sorted, it’s time for the semantic side. I’m not thinking about technical semantics, but rather business semantics.

On more than one occasion, I’ve had a head-beating-wall conversations with WCF folks who are completely obsessed with the secure, reliable and transactional delivery of messages, but have given exactly zero thought to the actual contents of said message. So I know where Jimmy is coming from.

With respect to AJAX toolkits, the question becomes just how easy will these lightweight toolkits compose? Because while Dion describes Google Maps as “a simple JavaScript include”, that’s just the technicalities, it doesn’t begin to deal with the semantics. For example, Dojo has Dictionary object, prototype has a Hash object. Dojo extends the Javascript Array, so does prototype. Both libraries wrap the XmlHttpRequest object. In each of these cases, it appears to me that the library authors have focused on the technicalities, but not thought about the semantics. These implementations are all semantically similar, but incompatible. So I don’t buy that these lightweight toolkits will compose well. What do I do if I’m using prototype but want the rich text editor in Dojo?

The network effect that Dion doesn’t consider is the component ecosystem phenomenon that Microsoft has a ton of experience with. Old school VB, COM/ActiveX and .NET have all had large ecosystems of components and controls evolve that extend the functionality of the baseline development platform. There’s no reason to believe that won’t happen with Atlas. I think it’s wrong to describe Atlas as a monolith or self-contained or enclosing. It’s an extensible baseline platform – i.e. the baseline functionality is set down once at the development platform and the ecosystem can extend it from there. Sure, overlapping extensions happen (how many rich text editor components are there for ASP.NET?) but at least they all have basic compatibility.

Update: Fixed link to Dojo Toolkit in the first paragraph.

In his now-famous talk, Dick Hardt describes Identity 2.0 as inevitable. As in “coming for sure, but not here yet”. I wonder how much of Web 2.0 is here now, and how much is inevitable? And furthermore, how much can we generalize about the future of Web 2.0 from what is happening now? As in many things, I think the answer isn’t black and white.

For example, I think we can generalize about the bright future of peer-to-peer based technologies from looking at systems like Skype and FolderShare. Naturally, with the power shifting to the edge, I believe it’s inevitable for more edge machines to communicate directly with each other rather than being mediated by a service in the center. In fact, in many cases I believe were going to want to shift a significant percentage of social computing to the peer-to-peer model. It scales better and doesn’t have centralized privacy concerns. Furthermore, I think there may be be specific peer-to-peer capabilities that are difficult or impossible to replicate with a centralized model, though so far, I haven’t them yet.

However, I’m not sure we can generalize about the future of mashups the same way. This isn’t to say I think mashups are going away – far from it. I just think that mashups a year from now will look very different than they do today.

First off, I don’t think we can  generalize the success of Google Maps. In the Programmable Web how to guide, they mention that “Plotting markers on maps is probably the easiest place to start”. Apparently, many people are taking that advice because 297 of the 411 mashups listed use one of the three major (i.e. GYM) mapping services. However, maps are unique because of the massive amount of data, the extremely simple API and the ubiquity of location information. They are also one of the few mashup API’s that runs in the browser – the vast majority of mashup API’s are back end data type services like Amazon’s E-Commerce Service. How many more in-browser mashup API’s are out there waiting to be built? I’m not sure, but as I wrote in Browser as VM, the problem with these in-browser mashup API’s is that you can’t protect your IP.

As for back-end service mashup APIs, there needs to be a way for these service providers to make money. Even if the software they use to build the service is free, things like hardware and bandwidth are not. For an Amazon or Ebay, making money on thier services is relatively easy since they are facilitating sales transactions. In the end, they probably won’t care much if a sales transaction originated on their site or on a site leveraging their APIs. However, if the service provider is ad-funded, the service API effectively routes around the site’s revenue mechanism. Take, for example, a site for tracking events like Zvents, Eventful or Upcoming. They need to drive users to the actual site in order to drive revenue. So it remains to be seen exactly how the API based access is going to work out. Today, these API’s are specifically provided for “non-commercial use only” so one way would be to charge for access via the API (either flat-rate subscription, a per-use charge or a combination of the two). Alternatively, they could be bought up by a larger company who could then afford to run the business at a loss. Yahoo already bought Upcoming and Google Base already has an event item type, but the other big companies in this space (I’d guess Microsoft, Amazon, Ebay and maybe Apple) might be interested. Again, I’m not sure how this evolves either, but it’s got to evolve beyond “non-commercial access”.