This is a verbatim copy of an emal I sent to Brad Feld of Mobius Venture Capital.
Brad, I appreciate you taking a proactive role, but there’s something that’s not right about all this — we need to get out of the backchannel and have this discussion in public. So many reasons for it.
1. People, rightly, complain that they had a right to be in the loop on whatever we’re talking about. They absolutely do. I know what it feels like, because I’m completely in the dark on how Rogers got to this point. At one point in the discussion with he, myself and John Palfrey at Harvard, they took it private, and I didn’t even know the conversation was continuing. There are too many dark spots.
2. If you recall, I asked if questions about RSS would be decided in Feedburner board meetings. Of course they would have been if this had gone forward as conceived. Do you see how wrong that is? RSS is not your property.
3. You talk about examining the record. It’s important that people be able to do that. Well, people coming back trying to figure out what happened here, unless Rogers decides to show us his mail archives, won’t be able to do that.
4. There are other dark spots Brad, places you and I can’t get into. Those are the times other people tried to take RSS private, to take it for themselves. I’ve never seen the converse, a private discussion that resulted in something good for the community.
5. Backchannel begets more backchannel. If you’re working with Rogers in the backchannel, then I have to work with you in the backchannel, otherwise he has an unfair advantage, and when we’re in conflict like this (not my choice btw) I can’t give the other guy that kind of advantage. Even so most all of what I said, I said in public where everyone could see it.
6. RSS is a public thing. I don’t know how to say it better. Since you’ve made such a big bet here, I think you need to understand this. This probably won’t be the last mess you’ll get dragged into. This is one of the reasons I sought you out at Gnomedex. RSS is serious stuff, and not much fun, I’m afraid. But it’s very important that it be protected.
So my feeling is, if you have something to say about this, it should be on your blog or on a mail list, otherwise don’t say it.
Dave
PS: I’m cc’ing Palfrey, so he can see how this looks. I have no visibility into his conversations with Rogers, I don’t know who decided to cut me out of the loop, or why. (I have ideas about that, but I don’t actually know.)
Scripting News Annex 
Posted by Dave’s Wordpress Blog » Scripting News for 2/25/2006 on February 25, 2006 at 7:13 am
[…] Essay: Why the back-channel is bad for RSS. […]
Posted by Brad Feld on February 25, 2006 at 8:41 am
Here was the note that I sent to Rogers that prompted this reponse from Dave.
Rogers – we’ve never met so I’m being presumptuous in writing you. Hopefully you’ll take my comments as constructive, which is the manner in which I’m offering them. I’ve copied Dave Winer on this as he’s the person that has raised the issue that I’d like to address. The construct of RSS (and feeds / syndication in general) is important to me as I’ve made a number of investments in companies working on things in this area, including Technorati, NewsGator, and FeedBurner. I view RSS and other syndication technology as fundamental protocols – similar to the relationship between SMTP and email. Time will tell whether this is right or wrong, but I’ve had a lot of success helping create a number of email-related companies (while staying relatively distant from the evolution of SMTP) and am now working on creating a number of syndication-related companies.
I found out about the RSS Advisory Board relatively recently (via a search feed on one of the companies I’m involved in that linked to one of the posts.) I took at look at things, realized that Dave Sifry, Greg Reinacker, and Eric Lunt were on it, read through some of the stuff on the site, and figured “hmmm – that sounds useful.” I then went on to the next thing.
Last week, I was alerted to some of the conflict that was developing around the board. I started watching the posts on the public list and saw the discussion begin to devolve. I checked in with the companies I work with to find out the history (I’m peacefully naive about a lot of the history and evolution of the RSS) of the RSS Advisory Board as they knew it. The general response was “it sounded like a good thing – when asked to join I agreed in order to help out in any way with the broader community.)
Dave Winer (who I also do not know very well) contacted me directly and filled me in on his perspective on the history, as well as the current dynamics. I then spent some time looking into the history to try to be better informed. Granted, I really only looked at what was public available, but thanks to Google, Yahoo, and a lot of the persistent storage on the web, I was able to quickly find more than I cared to look at.
The other day, I saw Dave’s post – http://www.scripting.com/2006/02/23.html#anOpenNoteToRogersCadenhead. In it he suggested something straightforward that – if taken at face value – seems to address the core of the issue. Specifically, Dave stated “Change the name and charter of the group you’ve started. Decide whether you’re working on a profile or a new format. You can’t do what you’re doing and call it RSS …” I sent Dave a note and asked him if a name change “away from RSS” solved the issue that he had and he confirmed that it would.
So – I’d like to suggest that you change the name of the RSS Advisory Board to something that eliminates the controversy. Why not call it something like the “Syndication Protocol Working Group.” At the same time, work with Dave to clarify the charter so it’s consistent with what has historically been done. By doing something like this, you can presumably eliminate the politics, move past whatever history (good and bad) exists, and spend 100% of your time on constructive activity.
I apologize in advance for being prescriptive without having previously spent time with you or gotten to know you in any way. My colleagues have lots of respect for you and what you are trying to generally accomplish. However, no one – presumably you included – has time or energy to spend on non-productive activity, especially when there is so much great stuff going on around this technology.
I’m available to talk anytime (although I’ve already spent much more time on this specific issue than I care to.)
Posted by John Handelaar on February 25, 2006 at 9:29 am
Entirely seeing both points, as I do, what I can’t see is a way out.
Dave, your opinion is clearly that “enclosure” is singular — I can’t see an opinion readily to hand about where HTML should or shouldn’t be allowed.
Without a revision to settle it, won’t things like this keep happening?
Posted by Dave Winer on February 25, 2006 at 9:44 am
The way out is: “If it ain’t broke don’t fix it.”
If RSS is broken, give me more broken things.
After all the wasted energy in XML-Land, why don’t people get that the reason RSS is the juggernaut that it is, and all the other stuff failed, is that RSS can be implemented easily and quickly and it isn’t a moving target.
In any case, why should you fix it? Why shouldn’t someone else? And what if they don’t agree with you.
Posted by Dave Winer on February 25, 2006 at 9:46 am
Here’s a puzzle for you.
1. Assuming people like new and better stuff.
2. Assuming Atom 1.0 is better than Atom 0.3 (it certainly is newer).
3. Why is Atom 1.0 not getting adopted?
That’s what the Atom-enablers don’t like to talk about, btw. 🙂
Posted by James Robertson on February 25, 2006 at 9:51 am
As to “broken”.
You might consider this examination I did (http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3318232350), and then go back to the list Rogers put together of variant tool behavior. When confronted with an item that has more than one enclosures, different tools react as follows:
— some take only the first enclosure
— some take only the last enclosure
— some take all enclosures
Which is correct? If you look only at the spec, any of them might be. If you don’t call that broken, then I’d suggest that you have no idea what the word means.
Posted by Dave Winer on February 25, 2006 at 10:14 am
James, okay, thanks for the suggestion.
In any case, suppose, just for the sake of argument that the spec was “clarified.”
Explain to me, carefully and slowly, how this would work, who does what, when, and then how does that help you.
Posted by Dave Winer on February 25, 2006 at 10:18 am
For extra credit, explain why your proposal can’t be implemented as a BDG or a “Best Practices” doc.
Posted by Dave Winer on February 25, 2006 at 10:24 am
James, why do you post stuff like this.
http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3318320907
It makes it so hard to take this thread seriously — how will you summarize this?
Why should I invest any time in discussing this with you, when your jugement is so superficial, harsh, unfair? How are we ever going to get anywhere if you won’t take me at face-value?
These are serious questions.
Posted by Chris on February 25, 2006 at 11:06 am
So, if something is popular it never gets fixed? As a producer of podcast curriculum for education, I’d like to know if I can or cannot use multiple enclosures in a single podcast entry. My students shouldn’t receive lesson 1 only, lesson 3 only, or lessons 1-3 depending on their aggregator. This is clearly an ambiguity (what the rest of us would call an error, but that seems to offend you) that should be fixed.
Dave, how do you propose this gets fixed if not through a revision of the spec? By getting the tool vendors to agree on what the proper use is (some kind of “stealth fix”) but never actually changing the specification or releasing a new version?
You are very vocal about what you don’t want people to do, but you don’t provide much guidance on how to actually fix the very real problems. Starting a third format isn’t the answer because, tes, RSS is great and it is being used all over. That doesn’t mean these errors aren’t real because, ultimately, the USERS are paying the price.
Posted by Roger Benningfield on February 25, 2006 at 11:08 am
Dave: “Explain to me, carefully and slowly, how this would work, who does what, when, and then how does that help you.”
I dunno about James, but I’ll answer those questions if you’ll answer one in return.
How it would work: Everyone joins a mail list and consensus is sought.
Who does what: The community of RSS developers.
How does that help me: My users are happy because I know what to do with the enclosures I find.
Why can’t it be a best practices doc: It *could* be, if said doc were described and linked to from the spec, as with the description examples authored by Nick Bradbury.
Now for my question… why are you fighting this clarification effort, when you were all for clearing up the “HTML in rss:description” matter? (A very, very positive change in the spec, by the way.)
Posted by Dave Winer on February 25, 2006 at 11:13 am
Roiger, the bug is in the first word of your first line. “Everyone.”
Do you have any idea how huge RSS is? I doubt if there’s mail list software that could handle that many people even if you could reach them all and convince them all to join your mail list.
Further, no consensus would develop. We know that because even with a very small group of people no consensus developed.
Not sure what you think I was in favor of. As to explaining myself, I have been writing all week doing that, so please read the archive.
Posted by Shannon Whitley on February 25, 2006 at 11:35 am
I’ve been doing a lot of work with various feed formats for the past several months, spending many hours parsing, extracting, and making exceptions for variations. The power of RSS 2.0 is that it is simple, widely accepted, and stable. I have some things that I’d like to add to the RSS spec, but I will plan to implement them in custom namespaces. Where I’ve needed to, I use RSS as a core component, and then build custom XML around it.
I agree with Dave that the discussion of changes, if any, should be very public and open to input from everyone in the community. Stability of the spec must be maintained, or we’ll end up with the same problems that we are now experiencing with HTML and javascript, writing special code to handle everyone’s “version” of the spec.
Posted by Andrew Lasey on February 25, 2006 at 11:37 am
” My students shouldn’t receive lesson 1 only, lesson 3 only, or lessons 1-3 depending on their aggregator. ”
I think multiple items, 1 enclosure per item is the preferred approach here. I think you still have some window of to “gets only the last item” but it would be reasonable to expect an aggregator to provide access to all items in a feed that haven’t been previously retrieved. Everything I’ve used allows that.
What is your practice today?
Posted by Seth Russell on February 25, 2006 at 11:46 am
As a developer i must admit that it was easier and faster to make a RSS 2.0 feed (which i did for http://www.speaktomecatalog.com) than it was to make an Atom feed (which i did for fastblogit.com). I am actually thinking of switching fastblogit default to RSS 2.0. Now, to be honest, my problems might have been that i was trying to tune in to the most “modern” feed (Atom 1.0) but then discovered that mostly i couldnt get it to work with the aggregators that i was using; and then had to switch back to Atom .3 and change all of the revised element names … hmm, now why did they do that? I think Dave has a good point, RSS 2.0 is not a moving target, and other formats still are.
As a developer, what i really need is a “official” Best Practices document. I don’t want no stinking new version. As a consumer, i don’t even want to know the version.
Posted by Ben Houston on February 25, 2006 at 12:42 pm
This is in response to Dave mentioning above that consensus is difficult to achieve with large groups and it is also fairly difficult to have everyone shouting over each other on a mailing list. I think that Dave is right on the second point but not so much on the first.
With regards to the second point, I can back Dave up by pointing towards what happened with Atom. When the Atom standard movement was starting up it attracted quickly a hundred supports. The mailing list was overwhelmed and it caused chaos. A solution that Sam Ruby proposed was to move to a wiki and that worked well — it effectively allows for parallel discussions on specific topics in a managable format.
From my study of the Atom effort (check out wikipedia for more info) it does look like they were able to reach consensus even though they were a large group. I suspect that with effective leadership an RSS clarification/specification effort could succeed as well.
Posted by Randy Holloway Unfiltered 2.0 » Is RSS is broken… on February 25, 2006 at 12:51 pm
[…] Dave Winer: “If RSS is broken, give me more broken things.” […]
Posted by Dave Winer on February 25, 2006 at 12:55 pm
Ben, the difference is that Atom was new, and RSS is not. It’s widely deployed. Consensus isn’t the issue, breakage is. It really matters that the platform not break. I don’t care if Rogers Cadenhead doesn’t get that, nor does it matter if any of the others do. It’s not up to them whether it’s okay to break some of the people who have implemented the format. It’s right there in the Roadmap. It’s frozen. I don’t know why people keep ignoring that, it’s right there. It’s part of the definition of the format, as much any of the other parts. For good reason. You shouldn’t have to run to stay in place. I’m tired of arguing about this, I’m moving onto other things.
Posted by Andrew Lasey on February 25, 2006 at 1:44 pm
Stupid Unrelated User Question: I follow a link from scripting news to here and I see http://www.google-analytics.com flash by in my status bar. Now that I’ve noticed it once, I notice it on all wordpress blogs. What’s that about?
Posted by How To: Make Your Brain Hurt at The Blog 50 on February 25, 2006 at 2:08 pm
[…] These arguments over RSS, however, are retarded. And stupid. RSS works, and isn’t that all that really matters in the end? Bookmark How To: Make Your Brain Hurt […]
Posted by Michiel on February 25, 2006 at 2:51 pm
“RSS is serious stuff, and not much fun”
Wouldn’t that be a reason to not do it for everyone, including you?
Isn’t fun what this whole computer thing (broadness deliberate) is all about?
Posted by d.w. on February 25, 2006 at 2:53 pm
> 2. Assuming Atom 1.0 is better than Atom 0.3 (it certainly is newer).
> 3. Why is Atom 1.0 not getting adopted?
When was the last time a *new* aggregator shipped without Atom 1.0 support?
It is, it’s a slow process — as tools that support ony 0.3 get revised, they gain 1.0 support. Surely, as a developer, you understand installed base and inertia. That is, unless you’re not serious about that comment, in which case, IHBT, IHL, HAND.
Comment mirrored @ http://base.google.com/base/a/1009164/3366777805723743838
Posted by Dave Winer on February 25, 2006 at 3:23 pm
dw, I don’t know the answer to your question. But I am about to ship an aggregator without Atom 1.0 support. If you want to write a driver for Atom 1.0, I’ll consider including it. It’s not even on my to-do list. Not for religious reasons, I have no religion when it comes to support for formats in my aggregator, there’s just simply no reason to prioritize it, and there are always more things to do than I have time to do.
I’m not so sure about your second statement.
Of course I understand installed base and inertia. That’s what the discussion here is about. The reason RSS 2.0 was frozen was to let an installed base develop.
Posted by d.w. on February 25, 2006 at 5:13 pm
Dave — interesting. So your new aggregator, out of the box, won’t support Livejournal Atom feeds (or my Atom feed, or Sam’s, and I’m sure you’re just crushed 😉 )? Didn’t someone already write an Atom format driver for Radio? Do Radio drivers work in NewsRiver? Anyone? Bueller?
My second statement was simply that I’ve noticed most tools that support Atom 0.3 feeds have been gaining Atom 1.0 support through their natural upgrade cycles (e.g. NetNewsWire, Livejournal, Firefox, Bloglines.) That there are some large laggards (e.g. Blogger, Flickr) is both unfortunate and unsurprising. When they get tired of getting bug reports about their feeds producing deprecation warnings, they’ll do something about it. Priorities.
Anyhow, I think the goals here are (I hope) common — ubiquitous syndication that works for both users and publishers, without a lot of “having to know how to build an engine to drive a car” drama behind the scenes. That a certain segment of the blogosphere needs to “blow up” once a year to get there is sad, but a little amusing, too.
Posted by todd cochrane on February 25, 2006 at 5:35 pm
Dave
I think your on mark with the issue, personally I have invested a pile of money in the RSS space this year because I knew it wa not a moving target, I see people in this comment thread that are asking questions that most of us answered a long time ago. 1 enclosure per item and everything work, you start adding multiple enclosures to a single item and all hell breaks loose.
Regardless it is obvious that RSS 2.0 is the defacto standard and that is what we have built to, obviously we had to deal with the cowboys at Apple but i’m in the content delivery business and consider it the cost of doing business, but there idiotic actions did cost me money and whats sad is they did not have to be cowboys in there implementation. We will adopt additional stuff as compaines introduce it if it fits our business otherwise people need to leave the rss standard the hell alone.
Posted by Dan Dickinson on February 25, 2006 at 5:38 pm
It’s right there in the Roadmap. It’s frozen. I don’t know why people keep ignoring that, it’s right there.
Perhaps this is the problem, then – from the Roadmap, emphasis added:
Therefore, the RSS spec is, for all practical purposes, frozen at version 2.0.1. We anticipate possible 2.0.2 or 2.0.3 versions, etc. only for the purpose of clarifying the specification, not for adding new features to the format.
Perhaps the spec needs to be clarified about whether or not the spec can be clarified.
Posted by Isofarro on February 25, 2006 at 5:54 pm
Ben says: “When the Atom standard movement was starting up it attracted quickly a hundred supports. The mailing list was overwhelmed and it caused chaos. A solution that Sam Ruby proposed was to move to a wiki and that worked well — it effectively allows for parallel discussions on specific topics in a managable format.”
Actually it was the other way around. Atom started off as a wiki – the pie wiki. The amount of changes and updates were hard to follow. A few weeks later one mailing list was started where the real discussion took place, and the wiki took the role of being the place where discussion was summarised and conclusions documented, and where suggested improvements were formally documented in a spec text way for discussion on the mailing list.
Ben continues: “From my study of the Atom effort (check out wikipedia for more info) it does look like they were able to reach consensus even though they were a large group.”
The Atom group had the advantage of not having an existing format to break, and that largely removed the barrier to consensus. There’s no way Atom could have succeeded if it had to start with RSS2.0 and not break that format.
Its only now, after Dave Winer has pointed out that clarifications sought for RSS2.0 would break existing users am I now totally convinced that Atom was needed from a technical perspective. (particulary this insightful comment: https://scripting.wordpress.com/2006/02/20/newsgator-sixapart-feedburner-technorati/#comment-1817 )
Posted by Dave Winer on February 25, 2006 at 5:55 pm
Todd, thanks for posting that.
We need to hear more from people who use this stuff, to ground the discussion in the real world. These mail list guys are living in another world altogether.
Yeah, I know what it says about possible clarifications, and I know why it said that too, do you? (Hint: read the archive of the RSS-public mail list in the last week. It was totally, thoroughly, exhaustively covered. Not going back over that again. Sorry.)
DW, yes it runs Radio drivers, and it supports Atom 0.3. If Sam doesn’t have an Atom 0.3 feed, there are a lot of other places his feed can’t be read. I understand why he might do that, but then again I’m pretty sure he supports other formats, because I get his feed in my aggregator which is NewsRiver, which doesn’t support Atom 1.0.
See that problem. “If it ain’t broke don’t fix it” rules the world. It’s the old installed base thing we were talking about. 🙂
Posted by Dave Winer on February 25, 2006 at 5:56 pm
BTW, I noted that this week something very rare happened.
Tim Bray, Sam Ruby and I agreed on something.
I almost fell off my chair when I realized that.
There’s hope.
Posted by Phil on February 26, 2006 at 7:22 am
There is another practical concern of mine: the date format.
I believe that RSS, when used for its original intent, syndication — the use of RFC 822 dates is acceptable. [Yes, it was one of the Atom vs RSS debates. Enclosures being one of the others. On enclosures, my opinion is that nothing’s broken if you use only one. Knowing this and choosing to include more … is the problem of the feed creator (user or software).]
But, with regard to date representation, I think that the problem becomes more acute when *synchronization* not *syndication* is considered.
I’ve raised this concern to Ray Ozzie’s SSE spec team [which was apparently released with Dave’s endorsement, certainly his awareness]. They [the SSE spec team] seem to have decided that the “keep it simple” approach is the goal. I agree, in principle, but not in practice. I acknowledge that a custom namespace can be used and the problem is solved. But solved only for the feed producer. And it won’t hurt existing readers/aggregators.
But, when coordinating synchronizations, the greater time resolution allowed with RFC 3389 should become the speficication for SSE. This will allow sequencing and improve automated conflict resolution policies. In a perfect world, I’d prefer that RSS 2.x *relax* the specification to allow either 822 or 3389 date formats. I realize that to spec purists this is tantamount to a crime. But it’s a practical, real-world approach that wouldn’t break what is out in the wild, but allow subsequent development involving innovative uses of RSS to proceed with less concerns.
Posted by kosso on February 26, 2006 at 12:34 pm
Amen to that, Todd!
My 2p: One enclosure per item. Easy. Simple. As it should be.
Though, I used to ponder over choices of enclosures for bitrates etc. with the concept of multiple enclosures, but then I decided it’s easier to offer a seperate flavour of the feed with the different enclosure bitrates, if I needed to offer choices. Easier to track too. Same goes for offering different audio or video formats for a podcast feed – use another feed pointing to the other versions eg: A divx video podcast feed – Flash video podcast feed – Quicktime/iPod video podcast feed… etc. if you decide to encode for different
simple.
I’m not saying multiple enclosures are a bad idea though – like multiple attachments in an email. But this isn’t email/SMTP – it’s RSS 2.0 – and though it has not been specifically defined, I’m sticking to one enclosure per item for now.
Posted by kosso on February 26, 2006 at 12:49 pm
Another reason why I support one enclosure per item is for the future of devices which natively support podcast subsriptions and downloading via embedded parsing of RSS 2.0. ie: The device IS the aggregator – like the PSP or Archos devices can – and potentially, soon the NokiaN91 and no doubt alot more to come.
I see alot of variance going on the in type attibute of the enclosure for a simple mp3 file these days.
Making a simple seperate feed for each supported device format will make life alot easier and speed up development of the in creasing amount of netowrk capable devices which will soon be happily downloading your favourite show as you walk along the hight street.
Your ipod doesn’t like avi – your archos doesn’t like mov. etc. etc.
K.I.S.S.
Posted by John Palfrey on February 26, 2006 at 7:51 pm
Dave, you note above that you do not have visibility into all my e-mails with Rogers Cadenhead. That is true. But it is also true that there’s nothing of a public nature in those e-mails that you or the community need to know but do not. I’ve said publicly what there is to be said about my position, on behalf of the Berkman Center at HLS, which is on my blog at the link above.
The other items that Rogers and I discussed, and which I doubt will surprise you, included in relevant part:
– whether I would join his group (I was grateful for the invitation, and declined, in large measure to avoid any confusion or the sense that Harvard was involved in the group, which it is not);
– what our plans at Harvard are for the RSS 2.0 spec that we continue to host (as noted in my short blog post, our plans involve no changes to the spec whatsoever, though we are possibly changing the platform on which we host that spec for the purpose primarily of serving it faster to visitors, which ought to be utterly transparent to any user from the outside);
– and my interest/concern that any republication of the spec and the related documentation meet the terms of the Creative Commons license under which we make available the work freely available to anyone (including, but surely not limited, to Rogers’ group, and which obligation I take seriously, and hope others will too).
For what it’s worth, I agree with Brad’s view: there is value to clarifying how Rogers’ group relates to what’s come before historically and it’s essential that users are not misled as to what’s going on here and now.
-JP
Posted by Jim on February 27, 2006 at 11:01 am
Dave,
> For extra credit, explain why your proposal can’t be implemented as a BDG or a “Best Practices” doc.
When you need to read the “best practices” doc in order to handle a format correctly, it ceases to be a best practices doc and becomes part of the specification in everything but name.
If a best practices document arose that explains how to do things that the spec leaves ambiguous, how would that not be an addition to the spec?
As far as I can see, there’s four differences:
1. It’s not physically part of the same document. That leaves the best practices doc essentially “invisible” for people reading the spec unless they have prior knowledge.
2. It lets people sneak in updates to the spec without falling foul of your “no updates” rule.
3. It lets people sneak in updates to the spec without changing the name of the format.
4. It lets people sneak in updates to the spec without updating the version number.
I don’t see any value in any of those.
As far as I can see, the only way to fix the enclosure issue is to either break your “no updates” rule (either explicitly by changing the spec or in spirit by publishing a best practices doc), or to stop handling RSS enclosures altogether and publish an enclosure spec that does them in an external namespace.
Posted by Dave Winer on February 27, 2006 at 11:25 am
Jim, there are people who disagree with you, what should they do if you decided to change the spec to make their stuff incompatible? And some people, esp ones at big companies, are going to think they have the right to change it too. Then we have trouble where befoer we had peace. Sorry I’m into peace. It took a long time to get things to settle down. So I say NFW to more crazy mail list “fights” — which are just huge collossal wastes of time.
Posted by Phil on February 28, 2006 at 12:41 pm
I’m rescinding my request regarding date format. I believe that Dave has eloquently (and artfully) shown that even if it’s simple, it works. There’s a way to do what you want if you need additional behaviours like I want for synchronization (not syndication), I can do them myself and get, at a minimum, my generators and readers to do the right thing.