Dave Winer announced "The new target date for RSS 2.0 is Tuesday of next week. Maybe Wednesday. But no later than that." This is despite issues objections and issues raised by the likes of Sam Ruby and Ben Hammersley. An interesting thread on RSS was started over at Blogroots. I have a refreshing debate with Dave Winer ending with his trademark answer-tough-questions-with-the-same-question technique. (My apologies to Meg and all for taking the thread off track.) This dialog was constructive for me (and I hope others) because it help me determine that he is incorrigible and that I should spend my effort elsewhere. I'm starting right now.
There is some coalescing in the community on balancing the simplicity and extensibility (via XML Namespaces) of future RSS formats. The topic of constructive conversation is currently centered on RDF -- how can the "tax" by minimized or does it have a place in RSS at all? RDF is not fully understood by most to really say (a problem for RDF) so there is a lot of instruction on its merits being exchanged. Here are some links on the subject:
- DJ Adams: The RDF in RSS.
- Shelley Powers: RDF: As simple as A, B, C.
- XML.com: What is RDF?
- Ziv Caspi: RDF: As simple as X, M, L.
There seems to be two unification "2.0" formats that are resonating through the mailing lists and weblogs talking up RSS. One derived from the thoughts of Sam Ruby with refinements by Mark Pilgrim. Another is the RDF-friendly proposal made by Shelley Powers and refined by Sean Palmer. Interestingly both proposals break a certain amount of backward compatibility with previous specifications. This is still (at least to me) an outstanding issue -- compatable with what?
RSS 0.91 broke compatibility with 0.90. 1.0 is based on 0.90 while 0.92-0.94 is based on 0.91, but breaks backward compatibility with it. Yet most aggregators and toolkits (I just finished developing one) will derive basic RSS feed information irregardless of which specification a feed may or may not comply with. Standards are not as useful as applications, shouldn't the primary concern be a format that works with most applications rather then a specific standard or fork?
In order to settle this argument, I'm of the mind to let backward compatibility of the specifications suffer a bit in order to serve the greater good of developing a strong "core" with extensibility through namespaces. (I keep an open mind on RDF and have yet to form an opinion.) This is why I like and support the proposals by Mark/Sam & Shelley/Sean and will be studying them more closely.
Leave a comment