Syndication and competing formats

Adam Curry starts up a discussion about syndication formats from a user’s point of view. See google’s destiny is history, competing standards and users unite! I hope the message will get through.
I know, we’ve heard a lot about this, and it might seem draining and pointless. But the consequences for users are real. For each new syndication format that becomes popular, we lose an opportunity to get new features. Adding prototype-level support for new formats may be cheap, but experienced software developers recognize, first, that there will be at least an order of magnitude more investment for production quality support over time and, second, that they could have spent that time developing something new and exciting instead.
Why isn’t there better support for syndicating mp3 playlists? Why don’t we have better support for sharing category trees across blog systems? Why was MT-Blacklist, perhaps the best de-spamming tool around, built by a third party on donated time and not the vendor?
Sometimes I’m surprised that weblogs have survived as long as they have given the level of monkeying around. Witness Six Apart’s constant changes to the Movable Type default syndication format. Each time they change the default, weblog software developers must scramble to add support for that format whether they like it or not, because Movable Type is free (as in beer) and controls a significant chunk of the market. It doesn’t matter that MT supports the other formats, because most users can’t be bothered to learn about software sustainability and won’t be interested in fiddling with the defaults. I don’t get Six Apart. They’ve built a product that a lot of people like but seem to be doing everything in their power to kill the market in which that product thrives.
Google did a similar, but more evil, thing by using their free Blogspot users to proliferate the Atom format. Blogspot users don’t have the ability to add support for other formats, even though Blogspot already offers such support to their Pro users. Through Blogspot, Google is basically saying, “We could provide RSS support to our free users, it’s really just a switch-flip, and all newsreaders support it, but instead we’re going to provide this new format exclusively because, well, we just like it better.” To which I say, “It’s even worse than it appears”.
I Love RSS! If you like using weblog software and newsreaders, and want this market to survive, I encourage you to get informed, read the arguments, and support RSS. When someone claims that Atom is a better format, try to get them to explain what user-visible features Atom makes possible that are not currently possible. For each new feature (if any exist), consider both the benefit and cost of getting that feature. As a rule of thumb, each new feature will add a new form field or two to your weblog entry page. How many form fields do you want to have to fill out each time you write a weblog post? When someone claims that Atom is a more open format, try to get them to explain how a copyright owned by the AtomEnabled Alliance is more open than creative commons share-alike license from Harvard. When someone claims that Atom has a more democratic process, try to get them to describe the process by which decisions are made. Does every feature idea get a public vote, or are most of the decisions made by a select few. If every feature gets a public vote, is that really the best way to design software? If decisions are made by a select few, who are those people, how were they chosen, and who pays their salaries? Knowing the identities of the employer companies and their intentions is critical, because the companies, not the spec-writers, will own the intellectual property that comes out of the spec effort. When someone claims that the Atom has more to do with personalities than technology, take a close look at what each person has accomplished. Ignore the number of times the person made you feel good or smart, this is irrelevant. Pay attention instead to the amount of new and useful technology, particularly techology created by other people, that came into being as a direct result of that person’s efforts.

82 thoughts on “Syndication and competing formats”

  1. Thanks, Danny. RDF is interesting, but I haven’t found a personal reason to use it yet. I’m in the same boat with SOAP — my own needs for remote procedure calls are more than met by XML-RPC.

    James: I’m not sure what you mean by “RDF/Atom”. RSS 1.0 uses RDF, but Atom doesn’t. There’s three horses in this race — simple syndication (RSS 2.0), RDF syndication (RSS 1.0), and Atom.


  2. Phil: “I need to be able to include the less-than character in post titles unambiguously, and be certain that I’ve done it correctly, and that any correct client will display it as a less-than, not as part of a (broken) HTML tag, or interpret it as HTML, or strip it out entirely for fear that it’s HTML.”

    Dave: “You could replace the title element with one from a namespace. And that namespace could specify a much richer model for how title sub-elements could be attributed or nested.”

    But if there were such a namespace, then a feed using that alternative to the title element would be, in Dave’s words, “funky”, undermining the ability for different tools to interoperate, etc., etc.


  3. Andrew writes, “When someone claims that Atom is a more open format, try to get them to explain how a copyright owned by the AtomEnabled Alliance is more open than creative commons share-alike license from Harvard.”

    Here goes.

    Atom development will be formalized as an IETF working group. All IETF working group specifications are released with an IETF copyright and corresponding license. The working group that develops the Atom 1.0 specifications will be open according to IETF policies and guidelines, one of the “most open” of all standards bodies. After the Atom RFCs are posted, IETF policies also govern how existing and new working groups create official updates and changes to the RFCs.

    The RSS 2.0 specification has an Attribution-ShareAlike license that allows “anyone” to publish a new, modified version of RSS 2.0. However, John Palfrey and the RSS 2.0 Advisory Board have clearly stated that Harvard is the “official home” of RSS, which by definition makes all other derivatives of the RSS 2.0 specification “unofficial”.

    “Anyone” can make unofficial releases of *any* specification (even IETF RFCs as long as you don’t use the verbatim text from the RFC per their “no derivatives” license, which of course only applies to the *text* of the document, not the format or protocol).

    With Atom it is clear how open the IETF processes are for maintaining the official specifications. With RSS 2.0 it is clear that either the maintenance of RSS is not open (Harvard and the RSS Advisory Board) or that maintenance is “open” but unofficial.


  4. Hi Ken, I hear what you’re saying, but does maintenance by an IETF working group guarantee that a spec will be patent free? A simple, public “no patents” statement on the site would go a long way here.


  5. Thanks, Ken. That makes it pretty clear that we haven’t yet done a good enough job of expressing the problem. I know I can do it in an entry so long nobody will bother reading it. I’ll have to think about how to do it as an elevator pitch.


  6. Re patents, two part answer:

    One: While the IETF does not guarantee that a spec will be patent-free it does have a very strong disclosure policy and requirements for standards-track RFCs. A good summary is available at

    Two: Not only has no Atom contributor suggested any claim to intellectual property rights, but most if not all have stated that an open and unencumbered specification is a requirement.


  7. Ken: There’s no language in the Creative Commons Attribute-ShareAlike license that enables one group to claim its RSS 2.0 specification is official while others are not.

    The RSS 2.0 specification has been made available under an open license by a group that claims no copyright on the underlying format itself.

    What more can be said to make people recognize this?


  8. Man, I purposely stayed away from Atom because of the retards who support it. It’s pointless geekery and bickering over shit that will never make a difference to anyone of consequence…RSS is fine, why bother?


  9. Pingback: Workbench
  10. Pingback: 0xDECAFBAD Blog
  11. Ken, where did I or John Palfrey use the term “official” in re the spec on the Harvard site.

    Re: “Atom development will be formalized as an IETF working group.” Is this your opinion, or has the IETF made some kind of statement about this?


  12. Pingback: Random Static
  13. Rogers, I recognize the intent, I’m disputing its practical scope. Harvard owns and exhibits active maintenance over the original RSS specification. Anyone else’s specification is inherently a fork and irrelevant to the mainline RSS’ claim of openness.

    A torch just doesn’t get passed on by merely declaring, “I no longer own this torch”. As long as you’re holding the torch, it’s yours. If you pass the torch on to someone else, it’s theirs now. If you abandon the torch and somebody picks it up, it can become theirs as long as no one else disputes it strongly enough. But as long as you’re holding the torch, or haven’t passed it to someone else, or haven’t abandoned it, and another torch appears, it’s a different torch.

    There is absolutely no evidence that the RSS 0.9x/2.0 torch has been abandoned and is simply waiting for some volunteer to pick it up and run with it.

    (It was once stated that RSS/RDF “proves” the lack of control over RSS. It doesn’t. The ownership of the RSS torch was disputed, and now there are two different RSS torches.)


  14. Dave, the exact term was “the original”, as in, “As long as the original lives somewhere, there’s no question about what RSS 2.0 is.” John Palfrey confirmed that any other specification was a fork.

    Re. Atom going to IETF, it is neither my opinion or a completed action, it is a publicly stated goal with active progress towards that goal.


  15. Rogers, all projects can be outright forked. Atom itself is a fork of syndication.

    There’s a slight disconnect here because the Atom project’s claim of openness is not based on “ease of forking” whereas the RSS project’s claim of openness appears to disregard the RSS Advisory Board and emphasize the ease of forking. Nevertheless, my original answer addresses Atom’s openness (approaching an IETF process) and both aspects of RSS’ openness (RSS Advisory Board and forking to create new RSS projects).


  16. “Dear Mr Trouble, sorry for the irrational exuberance, thanks for reigning me in. I’m trembling wondering what punishment is waiting for me now. Sorry. ;->”

    My mistake… I didn’t recognize it was the IRRATIONAL form of exuberance, so it appeared to me to be overdone. My bad…;-D

    “You know what I always say when someone asks me the question you asked — tell me what you need in RSS that can’t be done by adding an element from a namespace, and then let’s have a talk about it.”

    Well, let’s talk then.

    Let’s talk process… The WWW: in this case Who/Where; What; When.

    If somebody wanted to propose a namespace, Who/Where do they submit it; What form does the submission require is the Who gonna do What with it; When can a response be expected by said Who???

    But first these questions: Will such-a namespace be called RSS 2.x, or something else, and seriously, I don’t see these questions being answered by namespaces! (snort…;-)

    “Usually it seems people don’t want to do this the friendly way. They seem to want to line me up against a wall with a blind fold on, in front of a firing squad and then tell me How It Is.”

    Well, a day and an evening ago I started a funny reply, but lost it when I brought this comment up. Your’s is funnier anyway, so:

    What kind-a sheet are you trying to throw over my eyes, Dave Winer…?!? At least you GET a blind fold, Dave!! Me, they just say “NO!! You do NOT get a last cigarette and you SHOULD-a quit smoking back when Dave Winer did!” Then they stone me and my proposals right before my half-alive eyes.

    Appreciate yer good fortunes, Dave, such as they are!…;-D

    “I think folk like Danny Ayers et al (the guy whose nose I’m supposedly up) imagine themselves as Clint Eastwood or Charles Bronson. Someone who rides off into the sunset, philosophical about a day well spent killing bad guys.”

    You and me seem to run inta more than our share, but apparently it IS our share… (?!?)

    “Instead, be an egghead for a minute, and answer the damned question. What do you need, and let’s see how we can get it, upsetting the fewest of carts.”

    Well I wuz gonna flame you a good one and still probably will, on another subject or two. That’s one way to tell if a person is serious about trying to be objective, or just paying lip service… However, don’t have the time now, and don’t see this as the place here.

    Perhaps another time and place? Not IN ORDER TO upset any carts, but because there’s a point.

    “Like you said in an earlier post, there are a lot of people with real jobs who implemented RSS and wouldn’t like to hear that they have to redo it. Nor should they have to, imho. Nor would they do it if I ‘told’ them to.”

    Your opinion is of NO import, Dave! Leave your opinion, in this case, OUTTA here!! (That a flame…?…;-)

    Iow, it matters not the least whether people “should” or “will” do this-or-that. Nor does your opinion on what they “should” or “will” do, as you said… There are, strictly speaking, no FACTS to deal with regarding ANY future-activity, of course. However, it’s pretty safe to say, based on what HAS happened: The vast majority of people ARE NOT going to rewire and rewrite code that works and provides utility.

    So let us, or at least you and me Dave.. or at least me, since your views may be different.. Let’s ASSUME people aren’t gonna ditch RSS just because Danny Ayers and a few other folks want them to, for little to no reason (imo?) and let’s treat this ASSUMPTION as a matter of fact. Let’s NOT treat this ASSUMPTION about the future as a matter of opinion. There’s no utility in doing that, unless you are a proponent of Atom. And I think this will thin the herd in this discussion quite a bit: Because those who don’t have real jobs will prefer to discuss how ditching RSS is MANDATORY in order for THE FUTURE OF COMPUTING to be REALIZED.. and those that do have real jobs can move on to the present.

    So, as a matter of fact, this brings us back to the question of how is RSS 2 going to continue delivering innovation, whilst at the same time becoming more stabilized and standardized??

    Is namespaces the ONLY way, I would ask??

    I have some additional thought/feeling/instincts in this regard, but would like to “hear” your “views” (and anybody else’s, tho I’m not going to commit to accepting ANY given notion any credence in advance of knowing what the notion is and who is advancing the notion).


  17. Arrrrgh…)-;

    Fergot.. I’d jes soon leave off with the Mr. Trouble, as Trouble’s my game not my name. And some lame fool is gonna abbreviate it, pitty the fool, to “Mr. T”. I look something like David Weinberger with long hair, only runtier.. so…;-D

    Also, keep trembling! These here were probably not the punishment you are seeking!!



  18. “Rogers, no offence taken – I respect your pov on RDF+namespaces. What I don’t respect is certain people’s exaggeration of the complexity in the interests of FUD.”

    Hm. I wonder if someone has mistaken my pov, since by point of omission, my pov APPEARS to be disrespected as well as misunderstood.

    First off, there is some confusion on someone or somebody’s part, of who are the FUDders and who are the FUDEES. This is partly the nature of competitive forces (like in competing “standards”, ie specs). If there is more than one over-lapping specification of ANYthing, then both (or more) of the proponents wish their spec to be the greater.. likewise the greater used. Since it’s hard to support two (or more) of anything, it’s easy for one to dominate in terms of attention, varying somewhat along usage.

    So part of this is a necessary outcome of using computers, however both Atom and RDF (“RSS 1.0”) are facing, not only FUD but, widescale adoption. RSS 2.0 hasn’t been facing difficulty getting adopted, except in some quarters of the computer universe(s).

    So, since I’d like to see SOMEthing in the way of a spec get adopted and utilized, I’d just soon leave off the FUD, and get on with the adoption. I guess that makes me partisan in these debates, to an extent. Nonetheless, there’s still quite a bit-a difference between FUD and adoption which, to be redundant, someone in this vicinity doesn’t understand and/or/nor agree with.

    Second off, the problem is that there’s widgets to do ANYthing, no matter how Rube Golberg. The further problem is that all this crap adds overhead, and it becomes far too EASY (rather than difficult) for overhead to get burried in the grid infrastructure. This second aspect of the RDF/RSS1/Atom vs. RSS2 debate troubles me more, btw.


    Where you say “I’m not sure what you mean by “RDF/Atom”. RSS 1.0 uses RDF, but Atom doesn’t. There’s three horses in this race — simple syndication (RSS 2.0), RDF syndication (RSS 1.0), and Atom.” I agree!!(!)

    This has been the focus of my points for some time: That Atom was specifically established to converge and/or merge (and/or negotiate)-; all these specs down into one format, and instead ended with three.

    What I meant was that there is one consistency that is found between RDF (RSS 1) and RSS 2, which is that both groups one there to be one-and-only-one format. Quite a bit of overlap, in this regard, so that’s what I meant by there’s a natural split here. (At least I’m not aware of many, (especially these days with 3 basic flavors to deal with,) who want RSS 2 to be THE ONE-AND-ONLY format in sydication.. Afaik (?) amongst those in favor of RSS2 being adopted… ?)


  19. Crap, (sic) “between RDF (RSS 1) and Atom”. (Also a minor-crap the cookie doesn’t keep my “personal info”…)-;


  20. Pingback:
  21. Yes, I’m way late to the game. No, I won’t be saying anything about the central topic of this post (for reasons that I will also simply refrain from saying). I did, however, want to clear up one misconception.

    Andrew wrote:
    “Why was MT-Blacklist, perhaps the best de-spamming tool around, built by a third party on donated time and not the vendor?”

    I developed MT-Blacklist over the course of four (almost) straight days of coding. I did at the very start of the comment spam flood, when it was nothing but a trickle. At the time, the one or two comments per week were annoying, but I guessed (correctly) that bigger things were coming.

    I was fast and the solution was solid. Before that, there was no reason to believe that we would one day spend even ten minutes of thought on spam on our websites. If you want to blame Six Apart for something, this isn’t it.

    Thanks very much for the compliment, Andrew.


  22. I don’t think Andrew was saying Six Apart is naughty or nice, he’s a good boy, using spam to illustrate that time spent fuzzing with formats is time that might be better used for other worthy projects.


  23. I realize this comment thread is just about dead, but I have one last comment on syndication of mp3 playlists.

    The reason why RSS doesn’t support syndicatable playlists is there is not a single member of the playlist community involved, or even really welcome, in the RSS world. We’ve been grinding away for over a year now, the concept of syndicatable mp3 playlists is 100% our invention, and nobody outside our community even knows what the issues are. RSS people are either going to have to retrace our steps from scratch or reach out to us to gain the benefit of our knowledge.

    If you really want to do this, you should start by grokking the new XSPF playlist format.


  24. Totally off-topic, but re. Mac OS X aggregators: “…and there’s a good chance that PulpFiction will give Brent someone to compete against in a Mac feature war to go along with the .Net aggregator feature war…”

    My new favourite aggregator for OS X is Shrook. Shrook simply rocks. The server-side offering (tracking read/unread state across multiple installations) fits my style.


  25. Pingback: Critical Section

Comments are closed.

%d bloggers like this: