TNL.net is designed for modern browsers but the content is still readable in older ones. If you want to ensure the best experience, please install a browser that was developed after 2009.

tnl.net

RSS and Media: Can’t we all just get along?

I keep try­ing to work on an entry to close the loop on the search engine and links research but RSS news is get­ting in the way. Last week, it was Microsoft’s wel­come endorse­ment and a new set of exten­sions and this week, it’s Apple and its announce­ment of a new spec­i­fi­ca­tion to add more data to RSS feeds used for pod­cast­ing. All this is nice but it seems that we’re see­ing the begin­ning of a fairly new bat­tle around RSS.

Some His­tory

Before I go into details about Apple’s new offer­ing, I want to give a lit­tle back­ground that will clear up some of my con­fu­sions. I’ve been involved in the RSS com­mu­nity since 1999, way back when it was just the domain of geeks.

Back in 2000, I made a few sug­ges­tions as to how RSS could be improved. At the same, the main ver­sion of RSS was ver­sion 0.91 and there was some inter­est in mak­ing a new ver­sion that would be called RSS 0.92 (yes, it was the alpha days of RSS). So five years ago, I was push­ing for crazy con­cepts like adding a date to an item or find­ing ways to attach sound files and video files into RSS feeds. Because of that, some peo­ple have asked me to opine on things like pod­cast­ing and my gen­eral con­tention is that pod­cast­ing is a good thing and that the way sup­port for richer files is imple­mented in RSS is much sounder than what I had offered in the past.

Sub­se­quent bat­tles cre­ated a fork in the RSS move­ment, with one of the main issues being the use of name­spaces in RSS. From there came the great split, with RSS 1.0 break­ing rank with pre­vi­ous ver­sions of the for­mat, and RSS 2.0 break­ing rank with RSS 1.0. Two for­mats, which moved in par­al­lel. Dave Winer did a great job pro­mot­ing the 2.0 for­mat and even­tu­ally, a major­ity started sup­port­ing it. Since then, a third syn­di­ca­tion for­mat (known as ATOM) has popped up and its mak­ing its way toward a 1.0 release. With all this, we’re see­ing a lot of smart peo­ple basi­cally try­ing to solve some of the same prob­lems, with­out really work­ing together.

A pro­posal

Look­ing at this, I pity the fact that it took us so long to get as far as we’ve got­ten. How­ever, with large play­ers now danc­ing in the syn­di­ca­tion space, I am start­ing to worry that things are going to get worse before they get bet­ter. As a result, I’d like to offer a mod­est pro­posal: let’s merge all this work and come up with estab­lished data sets that are com­pat­i­ble. The use of name­spaces for each ven­dor use is a great idea but shouldn’t one first think about what they are try­ing to accom­plish and look at prior art before try­ing to rein­vent the wheel? Let’s look at the exam­ple of today’s announce­ment from Apple.

RSS Does Media

So pod­cast­ing is becom­ing much big­ger. And video­cast­ing is com­ing soon. How about look­ing at media use in RSS. Wait, what do you know: Yahoo! has done some of the work already with the media RSS spec­i­fi­ca­tion (I know this is the sec­ond time in as many week that I’ve pulled out the Yahoo! name but it’s because they’ve been doing good work). The spec­i­fi­ca­tion pro­vides a num­ber of inter­est­ing things so I would sug­gest that Yahoo! and Apple devel­op­ers sit down together and come up with an agreed upon set of def­i­n­i­tions. Here are a few things that I would put on the table for dis­cus­sion by both entities:

  1. A com­mon name­space: it would be nice if they both agreed to a com­mon name­space. I’d rec­c­om­mend some­thing that does not include a ver­sion num­ber (a mis­take made in the Apple spec) but it might be nice to have it set as a DTD, which could ease validation.
  2. Add media:group to the final spec­i­fi­ca­tion, it looks like a very valu­able one, espe­cially for con­tent that is encoded in more than one way (this will prob­a­bly be some­thing Apple does not want)
  3. Retain media:category and have it replace itunes:category. Here, the Yahoo ver­sion seems to pro­vide for more flexibility
  4. Replace itunes:explicit and media:adult with media:explicit. What is defined as an adult varies from coun­try to coun­try whereas explicit is well, more explicit.
  5. media:text should replace the itunes:subtitle and itunes:summary but it should also get some­thing added to dif­fer­en­ti­ate the two (maybe a content attribute?)
  6. itunes:author could be taken care of with media:credit. Maybe this one could be required. The role of owner should be added to it and an extra attribute could be added for email which would cover the whole itunes:owner section
  7. itunes:images and media:thumbnail could be merged
  8. itunes:block is a good idea and could be cre­ated as a new media:block ele­ment which would also have a distributor attribute. This dis­trib­u­tor attribute would allow to block dif­fer­ent dis­trib­u­tors mov­ing for­ward so a cre­ator could decide to dis­trib­ute cer­tain con­tent only to cer­tain channels.

If both Yahoo! and Apple were to agree to do this, they would end up with a much stronger joint spec­i­fi­ca­tion and I believe it would also rep­re­sent a show of good faith from both com­pa­nies and an under­stand­ing that coöper­a­tion is good for every­one. I may dream but I hope that we will see this kind of part­ner­ship hap­pen, which is why I’d like to ask every­one to make sure to tell their friends about this entry. Together, maybe we can get Apple and Yahoo! to work together on clean­ing this stuff up (and any­one else who wants to play in that space, includ­ing Microsoft and Google). Oth­er­wise, we will see increas­ing frag­men­ta­tion of the mar­kets, which will result in less con­tent for each of the spec­i­fi­ca­tion proponents.

Originally published on June 29, 2005 in Technology . You may find related thoughts pieces under the following terms: , , , , , , ,