Every so often I get an email asking what's up with the RSS Advisory Board.
Here's what I thought in May 2004: "This group is not a standards organization. It does not own RSS, or the spec, it has no more or less authority than any other group of people who wish to promote RSS."
Today I think it's even less than that. It basically stopped functioning later in 2004. The people involved went on to do other things. In the meantime RSS kept growing and growing.
Did RSS actually need an "advisory board?" No, it didn't.
I think it's great that people care about RSS. Keep supporting it, and if you want to help people use it, great. Just don't pretend there's any official board or body or whatever behind it, because there isn't.
Oh and by the way this is where the RSS 2.0 spec is and always will be. (Modulo redirects and Acts of Murphy.)
Winer wishes the board he founded in 2003 didn't exist, so he's rewriting history to claim it folded up shop after he resigned. But if you go back and read his resignation, you'll find that he encouraged us to keep working on the spec and help developers:
After giving it much thought, I've decided to resign from the RSS Advisory Board, effective July 1. I feel that the process for clarifying the spec is now well-understood by the existing members, and we have started a positive working relationship with several leading aggregator developers. ... I wish the continuing members of the board the very best, and of course I will continue to be a huge booster of RSS and syndication technology, and I will offer my opinion, through this blog, naturally, as always.
As the lead author of RSS 2.0, Winer continues to be the most respected voice on matters related to the format. But he refuses to say anything that would help developers resolve points of confusion in the spec, such as the issue of namespace attributes.
Until he does, the board will do its best to address them. Our vote on revising the spec begins in five days.
Nicely handled. Are you available for the position of US Ambassador to the United Nations sometime in January of 2009? Me, I couldn't type through clenched teeth.
Roger, I don't want to make a habit of defending others' words but this post is a good example of how you are consistently misreading words of others so I'll make an exception.
Nowhere in the first quoted text has Dave ever said he *wished* the board didn't exist. All I read is that he didn't think RSS board was needed but it's great that people care about RSS.
And all that the second quoted text say is that he wish the board the very best and reserving the right to speak his opinion candidly. To me, it's just the usual amicable parting words like "good luck", not an active encouragement to keep working on the spec, particularly when his previous words are taken into context.
Misreading is not a good basis for community building, even when wrapped in words of diplomacy.
You're overlooking the part where he said "the process for clarifying the spec is now well-understood by the existing members." This is consistent with what he was saying to us privately at the time.
It's also consistent with the board's history. We revised the spec five times while he was leading the group from 2003-04.
So what is the 'process' as you understand it and how does RSS Draft 1, namespace-qualified attributes, and all the seemingly political invitations fit into it? None fits IMHO but I would like to understand your point of view because I simply don't at this point.
The namespace-qualified attributes issue came up in October on RSS-Public as we were drafting the clean rewrite of the spec. The board has not embraced the idea of adopting that spec, but the process of writing it has helped make the profile better.
If it were possible to address the namespace attribute issue with just a recommendation in the profile, we would not be proposing to clarify the spec. But one namespace implementation has no bearing on others. Namespace creators need to know whether they are allowed or disallowed to use namespace attributes on core elements.
I don't know what you mean by political invitations. Board members were recruited because of their backgrounds in various areas of RSS, professionally and personally. None were chosen because of how they might vote on any issues.
Namespace creators need to know whether they are allowed or disallowed to use namespace attributes on core elements.
And enclosure creators need to know whether they are allowed or disallowed to include multiple enclosures in an item. An issue which has been known, and discussed, for a much greater length of time.
There are two paths forward. One is to create a new format with a new name that addresses these and other deficiencies.
Another is to document, in a profile, what the issues are and what the most conservative and most interoperable path is for both consumers and producers.
To date, the RSS Advisory Board has been doing an admirable job of the latter.
It might make sense to re-label your current efforts as "Advisories" to implementors of the frozen 2.0 spec. Find areas of amibiguity and produce advice on how to interpret them. That's consistent with the groups charter... help developers make decisions.
Advise them on the enclosure question and any other pressing grey area
but forget creating spec's. It's a no win situation.
It's clear RSS will loose adoption ground without a clear standards organization to manage it. De facto standards always have their day and are codified into real standards to resolve these governance problems.
RSS had it's place but Atom is the solution that ultimately will give new uses of syndication a place to extend the ideas and add new features.
Our position on the RSS 2.0 specification has been moving towards this compromise: If we can deal with something using the profile, leave the spec alone and address it in the profile. That's how the enclosures, relative URL and HTML markup potholes are being filled.
But that's not possible with this particular issue. We can either tell namespace creators what the spec means with clarity or dodge the issue and pretend we didn't.
The RSS 2.0 spec actually is quite clear on this matter.
The RSS 2.0 spec, as it stands today, and has stood for years, clearly says "elements". Not "elements and attributes" but "elements". A different spec may say "elements and attributes" (or even "markup"), but this spec says "elements".
It may be the case some have chosen to ignore that part of the spec. It may be the case that some that such 'sins' are only 'venial' (I, too, am a lapsed Catholic). It may be the case that the author wished he had chosen different words. It may be the case that the author intended something different. (For the latter two, we may never know).
But none of this changes the fact that the RSS 2.0 spec, as it stands today, and has stood for years, clearly says "elements". Saying something different isn't any clearer, it merely is different.
Coincidentally I came across this delightful piece of f(r)ictional literature today. Do check it out, even if it were only for the hilarious video at the end:
Rodgers, I'm just an observer, without any "skin in the game", so take the following with that in mind - and I know I'm being arrogant in that I don't emotionally grasp all the ramifications, but ...
I suggest, bite the bullet already, and declare something like "RSS 2.0++" (the value of that name is you'll still get Google-juice for "RSS 2.0").
But I'm bad at politics.
I don't usually agree with Sam Ruby, but this time he got it exactly right. I have been really clear about this and consistent. There is an easy and fair way forward for your work. Either define a new format, or define a profile. I think Sam is saying he will work with you on the validator to add support for either path you choose. But saying you're "the" advisory board, working on "the" spec is clearly (imho) not an option for anyone at this time.
Then, by the way, you won't always have to ask (and won't be asked) what the intent of the author is, it won't matter. If you're trying to do a profile, then what people create will have to be both conformant to your profile and also validate against the RSS 2.0 spec. I think this is the preferable way to go (and is largely the way you are currently going). If it's a new format you're free to change any aspect of the RSS 2.0 spec you want, or create a wholly new format like Sam and Tim and the Atom folks at IETF did.
BTW, it would be helpful to see some evidence that you're presenting this to the group you represent. We can't post to your group list, and the only people posting these days seem to be you and Randy. I'd like to hear from some of the other members of your group Rogers. Thanks in advance.
The RSS Advisory Board has the ability to consider revisions to the spec. This was true under your leadership in 2003-04 and it remains true today.
You have an opportunity to point RSS developers in the same direction on issues like namespace attributes, item enclosures, and HTML markup outside of an item's description.
If you did, I'm fairly confident the board would follow your lead.
Cross-posted on the RSS-Public list.
I spent some time reading and thinking before responding, and have an idea.
There are just a few people who are dug in on positions that actually
are quite close, and the majority of people are not dug in, and want
to help the syndication community do better work. I'm not saying that
the people who are dug in don't want the same thing.
First, please Sam Ruby, stop casting everything I do, and others, in
such a negative light. We aren't so stupid, or conflicted, and it's
preventing discourse. I will not respond in the same manner to you, I tune out when you do it. Just today you did it on your blog, in
trying to revive an old disagreement that you don't really understand.
Second, Rogers and Randy, you have to give up the belief that you're
running the same advisory board that existed before Rogers joined it.
That group never had the charter that you've assumed, and it stopped functioning a long time before your attempt to revive it. Further, I
never envisioned that refinement work would be taking place on the RSS
2.0 spec almost five years after its publication. The goal was to
reserve a few *months* to debug it after it moved from the UserLand
server to the Harvard server, for link breakage, typos, and possible
catastrophic mistakes that needed correction (which thankfully,
never surfaced). You are way past the time for that kind of work. I
know you can find an exception, but that doesn't change my belief that
you can't be contemplating these kinds of changes this late in the
game, even if you were on the advisory board, and it continued to
exist, which I don't believe it does.
You keep asking me for answers, and I keep giving them to you, they're just not the answers you want to hear. I've consistently been saying "hands off" to your request that you or anyone else be permitted to change the RSS 2.0 spec.
Third, if there are other people actively participating in the group
you're running, it would be helpful if you could ask them to
participate in this discussion and consider the things I'm asking you
to consider. I don't mean vote on it, I mean participate in the
One of the things that really sparked my attention is Randy's advice here a few days ago, where he said something about item order that is absolutely not true. At that point I got an idea of how dangerous this work you're doing actually is. With only two people actively working on your board, and no real discussion taking place, you're going to make serious mistakes. You can do that if you're working off on the side, but to the extent that people believe that you're working on the real spec, well, you can see how scary that is.
Now, if we can get your group to do two things, I will offer a compromise of my own.
I will join as a member, if you want me to, to help give it legitimacy. At that point these time-wasting discussions can end. I would also suggest that you offer Sam Ruby a position, esp if he takes the first item here to heart.
The two things:
1. Recognize that the RSS 2.0 spec is on the Harvard server, and it is
not going to change.
2. Change the mission of this group to working on a profile. Let's
come up with a memorable name for the profile that doesn't sound
official or mandatory, and let's get to work on solving problems, and
then promoting the result to the users.
If there are pragmatic reasons why you can't do these things, I'd like
to know what they are.
And please give this some thought before you reject it, or argue against it. Think about what you want to do with your time, work on technology and help the community, or argue about your right to do it.