Notes for groups interested in RSS

Last night I posted several notes in response to a post by Paul Montgomery. We’re at an interesting point in the life of RSS, where several small companies, Newsgator, SixApart, SocialText, Feedburner and Technorati may be trying to control the evolution of the format.

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 five companies, Newsgator, SixApart, SocialText, Feedburner and Technorati, give themselves special position among the many companies using RSS, especially since UserLand unilaterally 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?

I agree completely that transparency of each board members motives, conflict of interests is very important and could help the cause. So I answered #4 for myself on The RSS Blog [http://www.kbcafe.com/rss/?guid=20060220072118].

Dave, what are your feelings on Jonathon Avidan’s effort to create RSS 3.0? (http://www.rss3.org). As an RSS evangelist myself, I’ve been hearing/ reading rumblings that RSS is lacking a few things and it’s not a W3C standard. (No doubt you’ve heard lots of stuff yourself 🙂

What I was thinking is that it’d be nice if the (X)HTML spec was modified to include a new tag, to aid auto-discovery. But I’m not sure if this would happen if the tag wasn’t generic. For example, if it was specific enough to include format, maybe it would get picked up by the W3C. E.g.,

Raj, people give so much weight to things I say about RSS, that I try to spend a lot of time contemplating things before I comment. I haven’t yet spent enough time contemplating the subjects you raise. 🙂

I can’t help wondering why the W3C isn’t involved. They have structures/processes in place to prevent or address your concerns.
Also their participation would ensure wider adoption and adherence.
I know “Stinking” politics as usual but I think its time for US to wake up and get some validity to the “Specification”.

At one point I suggested that the W3C start with RSS 2.0 and use it as the basis for the work they wanted to do on Atom, according to the Roadmap (ie with a different name), but they rejected the idea. That was a long time ago. Now, I would say that getting a consortium of companies involved is exactly what RSS does not need. There are already so many companies of all sizes and shapes using RSS, and most of them would want their interests represented if any were represented, that RSS is inevitably better in its current form than it would be after such a group got through with it. This isn’t theoretic, we tried it with SOAP, it was the largest working group ever assembled at the W3C, and it was a horror combined with a comedy of errors and it went on for years before giving up.

That’s one fo the reasons why I never tried to drive RSS down the consortium route. Been there done that, it didn’t work.

Dave, ‘I See’ said the.. On another note this new symbol is “Unofficial”? Who the hecks the officiator? “Harvard”? There is coherency in “standarization”. even if just the W3C propose, present, revise/review and adopt processes are in place. Later..Ahhh the aroma.

I not sure I understand the question. There is no officiator, this is all working on the honor system, based on a simple idea, that we all have the most to gain by interop, and somehow, as if by accident, we already interop, so why screw with it?

5. Is there a back-channel or are all discussions of your working group held in public on your mail list? Will the archive of the interim mail list that decided that this group should exist be made public? Will the emails that organized the work group be made public?

Almost all of my work depends on the success of RSS and therefor I have an interest in RSS succeeding (is that a conflict?).

Yes it is. Your primary interest is not in RSS, it’s in your work and how RSS can help your work succeed. I’m not criticising you for that – it’s perfectly reasonable – but it does disqualify you from any credibility as an active member of an entity with no mandate which represents, as Dave says, only a small part of the very large number of discrete special interest groups which now surround RSS.

Come on people, it’s so easy to make fun of Dave but the longer this goes on the more right you’re making him. Daddy took the T-Bird away already. Just drop it so we can all go back to sniping for fun. 😛 😉

Paul — I guess I don’t follow. Should only those with no interest in the success of the format be participating in the work? Does anything in the real world work that way? Does the standards body that sets safety standards for air travel exclude anyone who rides on planes?

Paul, please don’t make me out to be anything other than an adult among adults. That’s been one of the problems here, people project parental imagery on me, and that excuses infantile behavior. We need to get the level of discourse up to an adult level, and that means being careful about metaphors.

Now, I don’t want to in any way diminish your contribution. When we look back, I think your role will be seen as pivotal, and I really appreciate what you have done and continue to do.

Raj, What I was thinking is that it’d be nice if the (X)HTML spec was modified to include a new tag, to aid auto-discovery. …. if it was specific enough to include format, …

I’m glad it doesn’t include a the format. The consuming agent can determine the format. I am of the opinion that publishers should only publish one format. That way a person would never need to choose. I’m sick of seeing zillions of feeds all with the same data and not having any rational reason to pick one over the other.

What we need is a best practices documents for publishers and developers that is just about generic feeds. The different formats are really just like tooth paste brands. They are a distraction.

Fair enough Dave, point taken. I see it’s dangerous to use metaphor in this area. I thought at least “Daddy” was a bit more respectful. 😀

d.w.: If you have special interest groups participating in such a process, you need all major stakeholders present or it doesn’t work politically. As Dave has explained quite reasonably, to have all significant stakeholders involved in an RSS process would make it so cumbersome as to be unworkable, like SOAP. Better to leave an imperfect spec locked than have it captured by a particular faction to be pushed towards their narrow version of perfection.

Seth, I agree with you. One format would be very nice. Do you think it’ll ever happen, though? I figure that with technology, there will always be an alternative format. I was simply thinking of something like <feed url=”…” format=”rss” version=”2.0″>…</feed> to aid in auto-discovery. Just a thought.

raj, I’m not saying that there ever will be one format, or that such a circumstance would even be desireable. I am saying that, from the feed consumer’s point of view, and from the publisher’s point of view, it really doesn’t matter what feed is published or which feed is consumed. The only faction to which the feed choice is important is the developer; and for him\her it is a nightmare. That is why people should let this format choce fade to the background, hopefully some day to finally dissapear forever. Just talk of feeds and use the new orange button. The rest is confusion, political wrangeling, and techno horse shit.

The problem I have with the list of companies Dave mentions is that the primary focus of all of their very existences are quite limited. Each of those entities are fairly specialised and use RSS in a fairly narrowly defined way. For me, the beauty of RSS is the overarching simplicity that allows you to use it in a multitude of ways – for things you never thought possible. My great concern is that companies like the ones above will come in “simplify” the standard for themselves thus making it considerably more complicated for everyone else and far less effective than it is now.

One thing I like about the way RSS is “governed” is that those companies are technically not really stakeholders. They are users. That makes them no more important than anyone out there who has a blog and publishes their own feed. Unfortunately where power vacuums tend to exist, certain types of opportunists always seem to pop up in an effort to fill the void.

As for having some governing standards body, personally I couldn’t think of anything worse. RSS 2.0 has achieved true international standard recognition already without some body of technocrats lording around giving it their stamp of approval. It is a true standard, a standard accepted in practice.

[…] Sean Kaye: “My great concern is that companies like the ones above will come in ’simplify’ the standard for themselves thus making it considerably more complicated for everyone else and far less effective than it is now.” The companies are Six Apart, Feedburner, Technorati, Newsgator and Socialtext. […]

Wasn’t there are already a big argument about RSS2 not being Perfect? And a fork to make it More Perfect?

And yet RSS2 was the format for podcasts AS IT IS, including all the imperfections everyone complained about in the first place. If people really really care about doing tricks like multiple enclosures, can’t they use a More Perfect format for their podcasts instead? Either that or let go of the multiple enclosure idea, which is such a small little thing?

Sean: “My great concern is that companies like the ones above will come in “simplify” the standard for themselves thus making it considerably more complicated for everyone else and far less effective than it is now.”

The world already has a truly standardized, carefully defined syndication format… Atom. So I agree, anyone trying to make significant changes to RSS 2.0 would be wasting energy and doing more harm than good.

Thing is, I see no indication that anyone actually wants significant changes. They simply want clarifications, such as the one Dave added last year concerning rss:description’s content model.

Sean: “It is a true standard, a standard accepted in practice.”

That’s the problem in a nutshell… there is no standard practice. Ambiguity in the spec means that the publisher thinks she’s saying one thing, but my parser thinks she’s saying another. For example, she thinks she can publish two enclosures per item, and I think she can only publish one. The user experience is broken, but neither of us is technically wrong… so all the user gets is finger-pointing rather than resolution.

Speaking as someone who crawls and parses a bunch of feeds, there’s plenty of ambiguity in RSS. And here’s the bad news: It’s not going away, no matter how many people decide to make new versions of RSS.

Every time somebody decides to “fix” the standard, I get one more RSS variant to crawl. Frankly, the installed base of blogs doesn’t care–their feeds already work–and only a minority will pay any attention to a new standard.

Right now, I need to handle 3 or 4 flavors of RSS (plus minor confused variants–thanks Apple), and two flavors of Atom. Adding a new version of RSS is going to fix this how?

Now, if you want to do something about ambiguity, write up an unofficial “RSS 2.0 best practices document” (based on current consensus, without claiming to rev the version), and gently encourage people to move in that direction. This would help to reduce the number of odd, funky interpretations of RSS 2.0 without further confusing the situation.

Eric said: “Every time somebody decides to “fix” the standard, I get one more RSS variant to crawl.”

If that is the effect of clarifying certain aspects of RSS2.0, then its looking very much like RSS2.0 as a specification is unworkable or broke. For example, one of the clarification points being discussed is whether you can have one or multiple enclosures. Now in the wild, all manner of flavours are available, for a variety of different reasons.

Now if the RSS Advisory Board adopts Dave Winer’s stance that there can only be one enclosure on a feed item, that surely shouldn’t force you to support an extra variant? That would suggest that the code you have now can’t accept a feed item with a single enclosure.

On the other hand, if they go with a recommendation that multiple enclosures are allowed, if you are handling the feeds that are already out there, then your code should already be handling multiple feeds.

Unless of course you supporting RSS2.0 purely on what the specification says, rather than what’s out there in the real world, in which case I’m sure the RSS Advisory Board would be interested in how you’ve interpreted a number of sections of the RSS specification.

But, I think you still have a good point – its looks far too late to fix the problems in RSS2.0, the horse has already bolted. Judging by your statement, RSS cannot be fixed because of the extra work required by yourself and every other RSS processor out there. That’s a fair reason for not clarifying anything in the RSS specification.

To Isofarro and James, you’re absolutely right that, if one were to come up with a new format that said specifically that you could only have one enclosure per item, it would make the aggregator developer’s job no harder (but it wouldn’t make it easier either). All it would do is create trouble for people with feeds that have more than one enclosure. And this is trouble I don’t feel is fair, nor does it get us anything. It may make you feel justified in flaming someone (James, I have felt the heat from your flames many times) but I don’t see why RSS should change just to give you some pointless and immature gratification. it wouldn’t make your coding any easier.

Apple changes the rules on developers all the time, and as a result apps break, and it costs money to keep up with them, and sometimes developers can’t afford to, and we lose their apps. I call this “running to stay in place.” Since RSS is now a platform, like the Mac or Windows, it has to decide whether keeping applications compatible is important, and it was decided, in the Roadmap of RSS 2.0. Now there have always been people who either didn’t understand that, or didn’t care, but they have ways forward, you just can’t use the name RSS, and that’s so you can’t flame them. If your idea is right, you have to sell them on your idea, I wasn’t willing to give you the higher moral ground. it’s easy to change a spec, it’s harder to make the installed base move.

Hopefully that explains it, and James I’m fully expecting a snarky attack on your blog, if it isn’t already there. 🙂

As it happens, across 316 feeds I subscribe to, as of yesterday, there were 327 items (in 18 feeds) with at least one enclosure. Of those, there were 3 feeds, with 4 total items, that had more than one enclosure. So:

— If the spec were clarified to state “no more than one enclosure”, then a small number of feed producers would have to change things

— If the spec were clarified to state “any number of enclosures allowed per item”, then tool suppliers would have to decide whether, based on the limited number of feeds using the feature, it was worth worrying about

— If the spec were clarified to state “one enclosure is recommended, tools that only support one should use the (first/last)”, then again, tool suppliers could adjust accordingly

What we have instead, under your preferred “do nothing” scenario, is wildly variant behavior across tools. An end user testing two aggregator tools against one of the feeds I listed with multiple enclosures would see different behavior, and have no idea (and no way to tell) which behavior is correct.

if one were to come up with a new format that said specifically that you could only have one enclosure per item, it would make the aggregator developer’s job no harder (but it wouldn’t make it easier either). All it would do is create trouble for people with feeds that have more than one enclosure. And this is trouble I don’t feel is fair, nor does it get us anything.

OK, so the answer to the question “can a feed item have more than one enclosure?” isn’t no, it’s yes. Right?

Haven’t you just clarified the ambiguity in the specification? Why would it be bad to have the spec clearly state that?

RSS is great becuase it’s an “open format” and it was tirelessly advocated to the market for adoption.

Changing the spec or not changing the spec has no real relavance IMHO to the evolution or the adoption of RSS. If that was the case it would have died a quick death years ago.

With that being said the RSS-advisory board should drop their assumption that changing the RSS-spec will somehow make RSS better then it is. No offense but it appears to me that the only real pupose to the rss-adviosory boards latest endeavorer is to control the market by controlling the conversation.

Dave Winer says: “if one were to come up with a new format that said specifically that you could only have one enclosure per item, it would make the aggregator developer’s job no harder (but it wouldn’t make it easier either). All it would do is create trouble for people with feeds that have more than one enclosure. And this is trouble I don’t feel is fair, nor does it get us anything.”

There’s the same problem in reverse. If one were to come up with a clarification to RSS that said multiple enclosures per item is allowed, it would make the feed generator developers job no harder. It would create trouble with aggregator developers that support only one enclosure.

By keeping the enclosure problem unclarified, both feed creators and feed readers are suffering.

The safest approach seems to be for feed creators to only allow one enclosure in a feed item (being conservative in what you send), and for feed readers to handle multiple enclosures (being liberal in what you receive). Otherwise a feed creator won’t be confident in knowing his feed will work in all RSS2.0 conforming readers – because some of them only support 1 enclosure per item. And feed readers won’t be confident his tools will support RSS2.0 conforming feeds because some of them have more than one enclosure in an item.

At least the feed creator has the choice, and can switch to Atom (RFC 4287) if they want confidence that multiple enclosures work. The feed reader can’t switch.

[…] RSS has no future. Don’t believe me? Just ask its creator, Dave Winer (link added by me): 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. […]