The RSS-DEV list has been alive with much discussion and debate to the future direction of the groups efforts. Bill Kearney made a motion to consider a potential name change of the specification given the nasty circumstances and the potential mass confusement that sparked a discussion of redefining the format's purpose. The extent of RDF's roll in what I humorously refer to as the "format formerly known as RSS" or FFKAR (I'm going to be called a problem or a rat or a monster yet) continues to be a hot topic of discussion and debate. I like what Sam Ruby and Mark Pilgrim proposed (stripped down core, namespace support, but no RDF), but I can't help but be intrigued by RDF and its declared potential. Late this week dove into the debate to play devil's advocate to the many well-meaning and passionate advocates of RDF. My hope is to strike a balance between the most RDF support with the least amount of markup while improving my understanding of RDF's merits and uses in FFKAR and beyond. Maybe others will learn from my public ignorance.
Jon Hanna posted his strawman year-zero proposal. It was an interesting and valiant attempt, but my personal view is the "RDF tax" (syntax and rules) are too heavy. The developer community will struggle to understand its use or value and soon thereafter revolt.
As I wrote on the RSS-DEV list, ideally I see the purpose of FFKAR as "...a simple (single?) focus that has broad applications is the way to go. Different 'features' and restraints will come from extensions (modules) and their combination dependent upon the problem domain." I continued, "[The format] should be a simple core of a handful of elements and an absolute minimum of required RDF structures. (Additional RDF would come through optional extensions.) It is a simple, yet extensible, format to represent a collection of resources (URIs) with meta data. When I think beyond news syndication and weblogging this notion of a "collection of resources" makes a lot of sense to me. It is simple and focused, but can be applied to virtually anything and extended for specific problem domains. It also ties into the principles of Web architecture that the W3C and REST advocates profess."
In the spirit of friendly debate and experimentation, I've created my own FFKAR experimental format proposal that is based on one first made by Shelley Powers and later refined by Sean Palmer. A simple version is here and a meta-rich version is here. The MovableType template files can be found here (simple) and here (meta-rich).
They are both well-formed XML and valid RDF. What I like about this format is how it streamlines the overall syntax and still supporting RDF. According to Sean's original post, its using the DAML list construct that has been approved, though not formally to be added, to the RDF namespace in the future. (The W3C RDF validator doesn't support this yet so I used the DAML namespace.)
My modifications where in fact minimal to what Sean produced. (Like I'm an RDF master.) I took the Dublin Core elements back out of the core in keeping with a small tight core. I also changed some of the tag names to all lowercase.
This format is not perfect, but it demonstrates what I think is an important consideration in these proceedings.
The redundant info rss:link and rdf:about will be questioned. Does this have to be this way? In order to not completely break existing aggregators and toolkits you have to leave the rss:link tags. In order to not break with RDF standards you need rdf:about. This is one area that perhaps will have to be solved with education and evangelization over time.
This format does break backward compatibility with all previous specifications. As I have mentioned asserted before the question of compatibility is a difficult one. Its my belief that, under the current circumstances, backward compatibility with existing aggregators and toolkits is more important. I tested both feeds with my liberal parser/MovableType plugin (worked fine) and AmphethaDesk (choked).
This format limits the file to one channel. Personally, I think this is a good thing, but others I know disagree. Someone noted on the RSS-DEV list (I can't recall who) that an item can belong to multiple channels. While understandable, I worry that this capability will be taken too far. The issues of bandwidth efficiency and processing multiple channels and mapping items are likely to outweigh the benefits. I make it a policy of staying out of trouble by avoiding it all together.
Food for thought. Your comments are welcome.
Mark Pilgrim points to Bill Kearney who asks "what's so bad about RSS 1.0?". My instinct is that that the added syntax for ordering is seemingly redundant and/or of little value to the average developer's needs now. This is a question I have to ponder further though. I'd be interested to hear others' thoughts.
Mark and DJ Adams continue their exploration in RDF sharing their links of interest and thoughts along the way. Thanks guys.
Mark has also begun experimenting with the RDF-based FOAF (Friend Of A Friend) format this weekend. Mark wonders what this buys him, but notes he'll try anything once. (Me too.) He is"scrounging" for FOAF files to add to his profile. I've added my FOAF to the world here.
Leave a comment