Some History
Before I go into details about Apple’s new offering, I want to give a little background that will clear up some of my confusions. I’ve been involved in the RSS community since 1999, way back when it was just the domain of geeks.
Back in 2000, I made a few suggestions as to how RSS could be improved. At the same, the main version of RSS was version 0.91 and there was some interest in making a new version that would be called RSS 0.92 (yes, it was the alpha days of RSS). So five years ago, I was pushing for crazy concepts like adding a date
to an item or finding ways to attach sound files and video files into RSS feeds. Because of that, some people have asked me to opine on things like podcasting and my general contention is that podcasting is a good thing and that the way support for richer files is implemented in RSS is much sounder than what I had offered in the past.
Subsequent battles created a fork in the RSS movement, with one of the main issues being the use of namespaces in RSS. From there came the great split, with RSS 1.0 breaking rank with previous versions of the format, and RSS 2.0 breaking rank with RSS 1.0. Two formats, which moved in parallel. Dave Winer did a great job promoting the 2.0 format and eventually, a majority started supporting it. Since then, a third syndication format (known as ATOM) has popped up and its making its way toward a 1.0 release. With all this, we’re seeing a lot of smart people basically trying to solve some of the same problems, without really working together.
A proposal
Looking at this, I pity the fact that it took us so long to get as far as we’ve gotten. However, with large players now dancing in the syndication space, I am starting to worry that things are going to get worse before they get better. As a result, I’d like to offer a modest proposal: let’s merge all this work and come up with established data sets that are compatible. The use of namespaces for each vendor use is a great idea but shouldn’t one first think about what they are trying to accomplish and look at prior art before trying to reinvent the wheel? Let’s look at the example of today’s announcement from Apple.
RSS Does Media
So podcasting is becoming much bigger. And videocasting is coming soon. How about looking at media use in RSS. Wait, what do you know: Yahoo! has done some of the work already with the media RSS specification (I know this is the second time in as many week that I’ve pulled out the Yahoo! name but it’s because they’ve been doing good work). The specification provides a number of interesting things so I would suggest that Yahoo! and Apple developers sit down together and come up with an agreed upon set of definitions. Here are a few things that I would put on the table for discussion by both entities:
- A common namespace: it would be nice if they both agreed to a common namespace. I’d reccommend something that does not include a version number (a mistake made in the Apple spec) but it might be nice to have it set as a DTD, which could ease validation.
- Add
media:group
to the final specification, it looks like a very valuable one, especially for content that is encoded in more than one way (this will probably be something Apple does not want) - Retain
media:category
and have it replaceitunes:category
. Here, the Yahoo version seems to provide for more flexibility - Replace
itunes:explicit
andmedia:adult
withmedia:explicit
. What is defined as an adult varies from country to country whereas explicit is well, more explicit. media:text
should replace theitunes:subtitle
anditunes:summary
but it should also get something added to differentiate the two (maybe acontent
attribute?)itunes:author
could be taken care of withmedia:credit
. Maybe this one could be required. The role ofowner
should be added to it and an extra attribute could be added foremail
which would cover the wholeitunes:owner
sectionitunes:images
andmedia:thumbnail
could be mergeditunes:block
is a good idea and could be created as a newmedia:block
element which would also have adistributor
attribute. This distributor attribute would allow to block different distributors moving forward so a creator could decide to distribute certain content only to certain channels.
If both Yahoo! and Apple were to agree to do this, they would end up with a much stronger joint specification and I believe it would also represent a show of good faith from both companies and an understanding that cooperation is good for everyone. I may dream but I hope that we will see this kind of partnership happen, which is why I’d like to ask everyone to make sure to tell their friends about this entry. Together, maybe we can get Apple and Yahoo! to work together on cleaning this stuff up (and anyone else who wants to play in that space, including Microsoft and Google). Otherwise, we will see increasing fragmentation of the markets, which will result in less content for each of the specification proponents.