Dave Winer's right. There, I said it.
I've mentioned Dave Winer a lot on this blog, and some of it could be classified under "snark". However, the recent move by Rogers Cadenhead and the RSS Advisory Board to develop a 2.0.2 version of RSS despite Harvard withdrawing its imprimatur strikes me as being against what has made RSS so popular, and I think Dave's in the right on this one. Yes, it's pretty obvious that Dave must have contacted the Harvard chums and convinced them to post their withdrawal in an effort to head off the threat to the 2.0 standard being set in stone forever, but that doesn't mean you should call him a "bearded fat guy", or a "big elephant", or a "bear" protecting its honey. EDIT: Or a "Big Dog". What is he, Beast Boy? Sheesh.
The Board's mailing list has been host to a very curious discussion of late. Randy Charles Morin, who is apparently behind the KB Cafe blog network including the RSS Blog, is one of eight new members and has been ringleading along with Sam Ruby. Rogers Cadenshead posts a perfectly legitimate query on whether the ongoing work in drafting new language for a spec constitutes "change", a scary word in the context of RSS since Dave Winer has said repeatedly since 2002 that the spec is locked in at 2.0. Randy posts the following in response:
and...
After that, Randy somehow comes to the conclusion that he has proven that clarification = change, and thus we need a new version, QED. This seems to me to be akin to sentencing someone to death in absentia, then going ahead and hanging them in absentia. As Sam said so rudely, you just can't change RSS without asking Dave Winer first. It's not smart. It's not polite. And, most importantly, it's not going to work.
I, for one, hope that the Board gets no traction whatsoever. I don't care that the Board's changes will make RSS "better". As a coder on an aggregator which reads and writes a lot of RSS files, my life would be a lot easier if RSS was better, but I don't want it to be. There are other advantages to the RSS spec which make it strong, and I want to keep them by sticking to Dave's correct decision to lock in at version 2.0.
The first is its vagueness. Technofetishists hate how non-conformist the language of the spec is, how it doesn't adhere to verb conventions or this or that secret scroll of RFC wisdom. I say, bugger that. Its vagueness makes it accessible.
The second strength is its state of stasis. That it has not been changed in years is a good thing. The fewer versions there are, the less special cases need to be tracked by parser scripts. More importantly, it has been frozen as a spec that services amateurs, and it is a great thing that RSS can not be subsequently twisted by commercial interests into something that loses its appealing simplicity.
The third strength is its poor quality, for the same reason of being a warning sign to big corporates: Keep Off, This Isn't For You. It drives the extropians crazy, but fuck them, it's not for them either. If they want a perfect spec then let them use Atom, that's what it's there for. RSS is meant for everyone else.
There have been a lot of passive-aggressive posts attacking Dave over the last day or two, plus some snide comments about anyone who is supporting him only trying to stay on his good side for commercial reasons. Bollocks. Dave Winer is not solely concerned with self-aggrandisement, he does stand for certain principles. I may disagree with his methods sometimes, but I stand with him on those principles.
The Board's mailing list has been host to a very curious discussion of late. Randy Charles Morin, who is apparently behind the KB Cafe blog network including the RSS Blog, is one of eight new members and has been ringleading along with Sam Ruby. Rogers Cadenshead posts a perfectly legitimate query on whether the ongoing work in drafting new language for a spec constitutes "change", a scary word in the context of RSS since Dave Winer has said repeatedly since 2002 that the spec is locked in at 2.0. Randy posts the following in response:
I wonder if that goal is attainable. I would suggest any new text will be perceived by somebody as a change. Clarifying that item title is plain text and not HTML is unfortunately going to be a change in the eyes of some.
and...
Each clarification we make is unfortunately going to be interpreted as a change by someone. The difference between clarification and change is entirely perceptual. And there's enough people that are looking for us to fail (this is syndication right?), that suggestions we are changing RSS will undoubtedly grow in time.
After that, Randy somehow comes to the conclusion that he has proven that clarification = change, and thus we need a new version, QED. This seems to me to be akin to sentencing someone to death in absentia, then going ahead and hanging them in absentia. As Sam said so rudely, you just can't change RSS without asking Dave Winer first. It's not smart. It's not polite. And, most importantly, it's not going to work.
I, for one, hope that the Board gets no traction whatsoever. I don't care that the Board's changes will make RSS "better". As a coder on an aggregator which reads and writes a lot of RSS files, my life would be a lot easier if RSS was better, but I don't want it to be. There are other advantages to the RSS spec which make it strong, and I want to keep them by sticking to Dave's correct decision to lock in at version 2.0.
The first is its vagueness. Technofetishists hate how non-conformist the language of the spec is, how it doesn't adhere to verb conventions or this or that secret scroll of RFC wisdom. I say, bugger that. Its vagueness makes it accessible.
The second strength is its state of stasis. That it has not been changed in years is a good thing. The fewer versions there are, the less special cases need to be tracked by parser scripts. More importantly, it has been frozen as a spec that services amateurs, and it is a great thing that RSS can not be subsequently twisted by commercial interests into something that loses its appealing simplicity.
The third strength is its poor quality, for the same reason of being a warning sign to big corporates: Keep Off, This Isn't For You. It drives the extropians crazy, but fuck them, it's not for them either. If they want a perfect spec then let them use Atom, that's what it's there for. RSS is meant for everyone else.
There have been a lot of passive-aggressive posts attacking Dave over the last day or two, plus some snide comments about anyone who is supporting him only trying to stay on his good side for commercial reasons. Bollocks. Dave Winer is not solely concerned with self-aggrandisement, he does stand for certain principles. I may disagree with his methods sometimes, but I stand with him on those principles.
posted by Paul Montgomery | 1:31 am
12 Comments:
The Atom guys truly did have the right idea, because, sometimes, it's important to be able to tell the "elephant in the room" to get stuffed.
Its vagueness makes it accessible.
There are areas of the specification where I think this is true. The vague purpose of item, for instance, has let publishers use RSS in ways that Dan Libby and Dave Winer couldn't have imagined when they drafted the first version of their respective specs.
But there are other places where vagueness give fits for publishers and aggregators. Can I use HTML markup in my channel's description? Can I attach two podcasts to an item? Is the name "Loïc" properly formatted for use in an channel's webMaster element?
The third strength is its poor quality, for the same reason of being a warning sign to big corporates: Keep Off, This Isn't For You.
The "Keep Off" sign isn't working. Microsoft is treating RSS like the killer app in its next version of Windows, and Yahoo, Apple, and Google all are working heavily in this space today.
You can argue that the RSS Advisory Board isn't the right entity to resolve the outstanding issues in RSS, but I don't see how it loses a two-person race against nobody.
Dave Winer here...
Paul, I appreciate the post, it raises some good questions, but I want to clear something up. I have largely tried to stay out of this discussion. A lot of people are interpreting a very brief post on Scripting News as meaning a lot more than it actually says.
Now I'd like to say a few things.
1. I think the Roadmap of the RSS 2.0 spec provides very clear instructions to anyone working in this area. I haven't heard anything from this new group that says they aren't respecting the Roadmap, so until I hear otherwise I'm going to assume that they are.
2. It's possible that a new format, based on RSS 2.0 could be an improvement, but any person or group attempting to do that must not in any way claim the exclusive right to do so, nor should it in any way attempt to interfere with the stability of the RSS platform. No one has the right to do that. RSS 2.0 is what it is. You can extend it through namespaces, that certainly is one way forward. You can take the format and make a new format as an evolution, but you must not call that RSS. That set of constraints has served us well.
3. I initiated the transfer of the RSS 2.0 spec from UserLand to Harvard in 2003 because ownership of the spec by a commercial entity such as UserLand had become a political issue on the mail lists and weblogs. I wanted RSS to have a future unencumbered by these concerns.
It concerns me to see four companies, Newsgator, SixApart, Feedburner and Technorati, give themselves special position among the many companies using RSS, especially since UserLand unilateraly gave up its special position with respect to RSS. It seems to me this is an issue that should be discussed publicly.
4. I would also like to know what interests the other members of this group have. Are they receiving money from the companies? Do they have any conflicts of interest? Do they assume a responsibility to disclose any conflicts of interest?
Finally, thank you for not raising personality issues about the people who raise them about me. It cheapens the whole community when people do that, if there's one thing that would help RSS, it would be more tolerance for differing opinions. And it's good to see that people who advocate a position similar to mine respect the rights of others. Thank you.
Dave Winer
Scripting News
Just a clarification: I was in no way trying to insult Dave with the bear line. I was just teasing my buddy Mathew Ingram based on some prior conversations between the two.
Apologies all around if I was inadvertently offensive to Dave or anyone else.
Paul: I can't say whether Dave is right or wrong, because it's not entirely clear (a) what the board will end up doing, and (b) how he will feel about it.
But I'm 100% in favor of updates to the language of the spec which clarify a few things (where is HTML allowed, for example) and make it more accessible. There is a middle ground between a vague WinerStyle document and the mind-numbing subsection barrage of an IETF RFC... I'd like to see someone hit that sweet spot with RSS.
My apologies if my comment was taken as rude. I meant no offence. It was merely meant as a literary reference to a person who nobody will name that has made a big and in every way relevant contribution to the discussion at hand.
Atom took great pains to comply with the RSS 2.0 roadmap. I would like to see anyone who continues with the RSS 2.0 effort do likewise.
Oh, and I would certainly qualify as one of those bearded fellows with weight control issues in this space.
Fat bearded guys represent!
I copied the RSS RoadMap excerpted from the RSS 2.0 specification and posted the excerpt to rss-public this week to establish a focal point from which the RSS-Board and most if not all current participants in the dialog seem to agree.
There is however something significant that is not being truthfully and factually discussed and we are in fact having the wrong discussion within rss-public and everywhere the tendrils of this discussion reach.
That is, first, there is no meaningful discussion to be held without the invocation of the name "Dave Winer" and secondly, at this point in time the only discussion that should be held first and foremost is that which can be held recognizing the facts that Dave Winer's best efforts were the result of the best efforts of a fallible human being who just just like the rest of us did the best he could but erred regardless where A.) despite his deep insight this person could not accurately foretell the future and B.) for whatever reason put forth incomplete implementations in at least two significant ways 1.) documentation and 2.) dysfunctional composition of several RSS 2.0 channel elements.
Now it must be said and clearly understood that I do in fact agree with the "spirit" of the road map and I do agree that we all should in fact respect and abide by the "proclamation" expressed by the road map, e.g. we really should avoid "changing" RSS 2.0 simply because we do not need to do so. Everything Dave Winer established in the proclamation regarding the use of modules and namespaces is in fact sufficient to "change" RSS to meet any extracurricular agendas.
But I ask, "would it or would it not be really lame to develop a namespace simply to implement a functional implementation of the skipHours, skipDays, pubDate and lastBuildDate elements while they continued to exist within the specification simply because the units of time expressed in the channel's pubDate and lastBuldDate were dysfunctional and could not be used to determine time correctly?"
So there must be a "however" -- and I know you were all waiting with baited breath for the 'however' right? :-) -- if we agree to respect the road map and only [amend | change | modify | update | clarify | whatever ] the documentation so as to "clarify" without responding to the fact that certain elements as implemented are in fact dysfunctional we will only needlessly perpetuate that which is dysfunctional simply because we have been too ashamed of our own shortcomings which do not allow us to maturely accept change which must in fact be made anyhow while pointing the finger at Dave Winer because after all, it was all his fault anyway; noting for those with reading comprehension deficits that I do not hold to that asinnine conclusion but do support and advocate both the major and minor premise from which it could improperly be drawn.
So I contend, this conflicting paradox is in fact the discussion we should be having. For if we do not [amend | change | modify | update ] the specification only (and I mean only) "to remove or correct faults in" we will still be trying to work with an RSS 2.0 which remains dysfunctional and if we leave the implementation dysfunctional we will not only have failed to meet the spirit of the proclamation expressed by the road map we will also have failed everything it stands for.
Consider the resultant circumstances. I for one do not appreciate the liars who have proclaimed their partial truths with regard to the skipHours, skipDates, or the textInput elements when they claim those elements "are rarely used" which we do know prima facie is a statement that has been established to be true in part but is put forth fraudulently simply because the partial truth is dependes on using a fallacious inference allowing the liars who tell such lies to say so only because the elements are dysfunctional as implemented. Nothing wrong with their intent. Dave was brilliant to see the need for such elements. They are simply crippled though, never completed as designed and entirely dependent on the dysfunctional representations of time as expressed by pubDate and lastBuildDate and that is all there is to it. Leaving textInput for another time I say when we resolve the conflict which currently prevents us from correctly expressing the value of a unit of time people will use skipHours and skipDates.
Nor do I appreciate it being left up to me to support this lie when compelled to explain and rationalize to people I work with or for who do not understand these facts when in the previous breath I was asking them to trust me because I am a man of character.
I resent the fact that I am being expected to conduct myself as a liar simply because software developers I would be honored to learn at least considered me a peer had some others amongst their midst who had an agenda which compelled them for whatever reason to avoid being able to say "hey, we have a prisoner's dilemma here yet we can not let this conflicting paradox stand. We have work to do so let's get at it."
Finally, I do not like the idea that I and others have been forked away from rss-public where I think we should -- all -- return to continue discussing these matters. So in closing for now, I say once again...
Truth is the elephant. coo-coo ka choo.
--- Clinton Gallagher
cc: rss-public
Mon, 20 Feb 2005 04:02:00 -0600 (CST)
Lack of clarity in a spec is not a virtue. Dave seems to think it is, because all his specs lack clarity. Those of us who implement on top of those specs suffer as a result.
The primary audience for RSS is users, not implementors. I'd rather have a spec that users can understand. Implementors should be smart enough to take care of themselves.
RSS is for users? Which users? Users using aggregators? Users writing RSS? Either way, vagueness of spec doesn't help users (be they readers or writers).
The primary audience for RSS is users, not implementors. I'd rather have a spec that users can understand.
I disagree completely. Specification documents need to nail things down 100%, and they can be as mind-numbingly boring as they have to be. THEN, you write a user-friendly overview document, with examples. And that friendly document can be as vauge as you please; it won't matter since it's only a summary.
Vagueness in a spec is not a good thing, ever. The spec is to make sure everyone is on the same page.
Users who want to figure out details of how something works will probably make a test feed, and see what their aggregator software does with it. It would kind of be nice if everyone else's aggregator software did the exact same thing too.
... "Dave Winer is not solely concerned with self-aggrandisement ... "
Gee.
You're pretty new around here, aincha?
Post a Comment
<< Home