Syndication Myths, Part II

In our previous post, we discussed the currently popular myth that most if not all feed clients understand all the major syndication formats. While we mentioned that there are a host of clients that don't understand one or more of the formats, we also discussed that this issue could go away in the near term as the syndication community either rallies around one format, or the number of clients in existence dwindle down to a couple powerhouses that support all formats.

The second (and perhaps more interesting) syndication "myth" we want to address is the notion that once there is some standardization on a single syndication format, all of the current syndication issues and challenges will go away. We happen to believe the following:

1. Syndication will become much more widely adopted as the preferred means of distributing "incremental updates to structured and networked data".

2. The extensibility of the syndication formats will cause companies to create proprietary namespaces for rich content, in order to obtain competitive advantage.

3. We will begin to see the emergence and then proliferation of niche consumer syndication clients that are optimized for handling one or two "types" of syndicated content (of course, we will also see the emergence of clients that are built to handle one or two particular feeds, but in these cases, the fact that RSS is the bearer format will be generally unimportant to the syndication community. Eg, Disney may use RSS as the bearer protocol for their ESPN motion client, but this doesn't really affect the syndication community in any real way).

What does all this mean? It means that even if we can all get along and agree on a common base syndication format and the number of different clients dwindles to a powerful few, the entire syndication space will simultaneously witness a growing sophistication and accompanied level of fragmentation through conflicting namespaces and specialty clients.

We are already seeing the emergence of one such example. Apple has begun syndicating genre lists and top songs via RSS for their iTunes service. If you look at the xml behind an iTunes RSS feed, you will see that Apple has created an RSS extension for "what it means to be a song"; the namespace is identified by http://phobos.apple.com/rss/1.0/modules/itms/. It contains extensions like <itms:coverArt> and <itms:albumPrice> to name just a couple. This extensibility is precisely what enables the syndication of rich media. Current RSS readers may not do anything with the itms namespace, but that's ok, because Apple also reuses existing base RSS tags to display things like the name of the band and song and a link to the song at iTunes. If Apple is smart (red herring), they will undoubtedly realize that an iTunes specific RSS client that understood the namespace would be a very powerful mechanism. Soon, you could syndicate your own playlists so that your friends could drop them into their iTunes client and the client would just alert you when you didn't "own" a particular song on the playlist, etc. This is great stuff, no? So, now let's say that somebody like Microsoft realizes "hey, we should syndicate songs to be playable in the Windows Media Player". Do you think that Microsoft will adopt the Apple itms namespace for what it means to be a song, or do you think they'll create their own slightly different namespace? Let's not just pick on Microsoft. Assume that Rhapsody or anybody else wants to launch some such service. We will undoubtedly have multiple namespaces for what it means to be a song, what it means to be a photo album, what it means to be a calendar of events, and so on.

Will such a fragmented set of namespaces on top of a base format or perhaps even fragmented namespaces on top of conflicting base syndication formats cause the promise of syndication to collapse? It need not. The beauty of syndication is that it's still all xml underneath, and where there's an underlying structure, there's a general ability to reconcile conflicting structures. One of the critical components to namespace reconciliation is this notion of subscriber-sensitive feeds. Something needs to be able to say "this request is coming from the Windows Media Player, so I need to hand it this feed in a specific format. The source feed is in some other format, so i will have to convert it". This is another reason we've architected FeedBurner to provide this notion of a subscriber-aware SmartFeed. As we begin to witness the syndication of rich media and extended types, many publishers will want to generate a single feed that can be understood by the widest possible array of clients.

As syndication continues to evolve, some namespaces will be standardized for greater community flexibility, while other fragmented namespaces emerge in order to provide companies with competitive advantage. Hopefully, we're thinking about this in such a way that we'll be able to help publishers all the way through this evolutionary process.