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”.
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”
Comments are closed.
Andrew Grumet's Weblog 
Well, you’ve given me plenty to think about!
Most of the people I know in fields such as PR, marketing, etc, are just now figuring out what blogs even are, nevermind the finer points. It seems that I’m often in the position if explaining these things and why they’re important, so I’ll be mulling this all over with an eye toward explaining all this in a way this other group of people can understand.
LikeLike
even tho i understand why they abandoned working with the RSS group, i totally agree here. why the f**k can’t i have a decent photoblog with MT? they’re “doing other things.” it totally irritates me.
LikeLike
“I hope the message will get through.”
Crystal clear: anything developers and users want that doesn’t comply to the Winer and friends gospel is going to be FUDded to death, regardless of merit. Any improvements to RSS which doesn’t originate from Winer and friends will be derailled and attacked in a concerted campaign of “Stop Energy”. Nothing _could_ be more clear.
“For each new syndication format that becomes popular, we lose an opportunity to get new features.”
The opportunities lost was a major drive toward Atom. You are not losing opportunities – you’ve already lost them because of the shambles around RSS2.0.
Creating a new syndication format which is Atom wasn’t the first thing tried – if anything it was a last resort. People have tried and failed to work within the RSS community — it is unworkable due to the FUD and nonsense starting from scripting.com and working outwards. That _prevents_ ideas from being worked on. RSS2.0 is the reason for the lost opportunities. Atom is an option to bringing back those opportunities.
So there was essentially no choice _but_ to start a new syndication format without this baggage.
“Why was MT-Blacklist, perhaps the best de-spamming tool around, built by a third party on donated time and not the vendor?”
Why do you have a problem with independant – vendor neutral – developers producing solutions?
“Each time they change the default, weblog software developers must scramble to add support for that format whether they like it or not”
Is the RSS2.0 specification now not good enough to define what is or isn’t a valid feed? Film at 11.
“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.”
I don’t get why people involved in Userland or Dave Winer seem hell bent on alienating a vast number of developers from the syndication space. Six Apart may have the power to kill the market they rely on, but Dave Winer and Co have done significant damage already (for instance, the loss of confidence in RSS as a result of his funky feeds spat – with no details.), yet that goes unmentioned. Interesting.
“they could have spent that time developing something new and exciting instead.”
Not within RSS2.0 – its history is littered with failed initiatives. If Winer doesn’t like you or doesn’t agree, nothing in RSS2.0 succeeds because of the negativity he generates.
“Google did a similar, but more evil, thing by using their free Blogspot users to proliferate the Atom format.”
So offering a syndication format on a free service that didn’t previously offer it is declared evil? There’s nothing wrong with proliferating an open format. Aggregators read Atom feeds already. Pity Radio couldn’t be bothered to upgrade their aggregator to support Atom.
“Blogspot users don’t have the ability to add support for other formats”
FUD. They never had that ability. Would you prefer Google not offer syndication for these free accounts – would that be _not evil_? Its utterly amazing that if a company choses not to use RSS2.0, they are branded as evil. Nothing but FUD.
If you want to insist you have a point, why does Radio have no ability to support Atom in its aggregator and feed generator? All the other mainstream aggregators and feed generators do.
Andrew, ask yourself honestly, what do you, Adam Curry, Dave Winer and John Robb have to gain by alienating the content syndication developer community in this way? This animosity you’ve (plural) crafted in the above post, how is that going to convince people working on Atom to give up and work on RSS2.0 instead? Looking at the number of failed initiatives in RSS2.0, its pretty clear that isn’t going to happen.
Alienating people trying to innovate with fresh new ideas isn’t a smart tactic. What are you gaining from doing so?
Its been emphasised over and over by you lot about how Atom is doomed to fail. So why not leave it be, stop this FUD and nonsense and let it fail. Surely if its failure is that obvious you don’t need to do anything but sit back and watch?
These posts over the last few days from the four of you border on desparation and fear. Certainly not the position of someone convinced of the merits of RSS2.0.
“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. ”
Wow, no option there of making up your own mind after reading the arguments. Hardly the modicum of unbiasism.
“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.”
FUD. Interesting that Atom is scheduled to be a proposed IETF – a recognised internet standards body – standard in August 2004. Something RSS should have done years ago (guess what stopped that from happening, or should I say whom?). Atom is and always will be a freely available open standard without any vendor dependance.
I see the biggest argument used against Atom is that Radio doesn’t support it. Radio is a Userland product, this anti-Atom effort is centered around Userland, its ex-employees and personal friends. Coincidence – I think not.
“When someone claims that Atom has a more democratic process, try to get them to describe the process by which decisions are made.”
Wiki discussion, mailing list discussion, people taking the initiative to try out different ideas and opening it up for discussion. Broad consensus reached. It is meritocracy based – for example the excellent AtomAPI was initiated by Joe Gregorio, discussed, improved and implemented by others – including myself. Never seen that happen in RSS2.0.
Note that the main figure-heads of Atom have actually not had their way in a number of key decisions. Far more democratic than the RSS2.0 process.
“Does every feature idea get a public vote, or are most of the decisions made by a select few.”
Public discussion resulting in a broad consensus. Working code goes a lot further than antagonistic remarks.
“If every feature gets a public vote, is that really the best way to design software?”
Public discussion. More times that not a general feeling of concensus is enough for. Seems to be working quite nicely, thanks. If it wasn’t a good method, Atom probably wouldn’t be as successful as it currently is, and you wouldn’t need to FUD as desperately against it.
“who pays their salaries?”
Who pays my salary has no relevance to Atom. You seem to be under this delusion that all Atom developers are being paid monetary compensation to do so. This is quite wrong. Who payed you to combine BitTorrent and RSS – same thing.
“Knowing the identities of the employer companies and their intentions is critical”
Who I work for is irrelevant to Atom.
“because the companies, not the spec-writers, will own the intellectual property that comes out of the spec effort.”
FUD. My employers do not have a claim on the work I invest into Atom.
“When someone claims that the Atom has more to do with personalities than technology, take a close look at what each person has accomplished.”
Yep, look at all the failed ventures in the RSS2.0 resulting from negative comments and FUD originating from scripting.com. Now look at Atom flourishing because Winer has no hold over it. Crystal clear.
“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.”
Define other people. Atom allows me to explore ideas that are impossible, too difficult or funky if done with RSS2.0.
Stop this FUD. You are so much better than this, Andrew.
LikeLike
If the RSS folks really want to avoid protocol proliferation, why don’t they jump on the Atom train?
LikeLike
“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.”
Sometimes I’m surprised that weblogs have survived as long as they have given the level of monkeying around. Witness Userland’s constant changes to the RSS syndication format ( http://diveintomark.org/archives/2004/02/04/incompatible-rss ). Each time they change the spec, weblog software developers must scramble to add support for that format whether they like it or not, because RSS is perceived as “simple” and “easy” and controls a significant chunk of the market.
Well, luckily, it doesn’t control a significant chunk of the market anymore. If you look at the number of sites that are only available in RSS, vs. the sites that are only available in Atom, RSS only has about 10% market share. 15% tops.
Thank God we’re over the Syndication Wars. We put up with that God-forsaken shitty little format long enough.
LikeLike
Others have critiqued your logic sufficiently, Andrew, but I have a specific question. Regarding the following sentence:
“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.”
It seems like your prescribed sequence is:
1. Get informed. This leads to:
2. Read the arguments. This leads to:
3. Support RSS.
In your opinion or judgement, is there any scenario in which someone can get informed, read the arguments, and support Atom? Or does everyone have to conclude with support for RSS?
LikeLike
“constant changes to the Movable Type default syndication format”? wtf? I’ve only been using it for a couple of days short of two years, but in that time the “default syndication format” (to the extent there is one, the one linked from the front page in the default index template) has been RSS 1.0 and nothing but, near as I can remember. There have been bug fixes, and that’s about it. The *lack* of a default syndication format, the fact that MT doesn’t know what templates are making feeds, or where it’s main feed is, now *that* is a problem. I’m having a hell of a time doing a plugin to do feed validation when an entry is saved, because there’s just no way of knowing short of asking the user (and having him forget he told you, when he changes things later). Other than that, yeah, they switched from a 0.91 to a 2.0 template. Would you like them to switch back, get rid of the 2.0 template? I bet they’d love to, after the crap they’ve taken of late.
Why was MT-Blacklist built by Jay, not someone on the payroll? Just guessing, but maybe it’s related to the fact that they launched TypePad, which actually makes the money that they use to pay someones to do programming? I may not like the way MT’s been on the back burner, but if I were in the position of choosing between getting a day job, supporting a few hundred thousand users at night, or starting a new paid service that would let me work on it full time and also pay for some programmer time for my free service down the road, I think I might go for the actual business.
But even if it wasn’t an economic matter, have you ever distributed a Perl app on hundreds of thousands of hosts, most of them cheap shared hosts, many of them bizarre things like an old ActiveState install on top of an old IIS server? Trying things out in a plugin starts out by raising the barrier a bit, to people who will install one, and makes it a “doesn’t work on your setup? well, doesn’t work, sorry.” thing when all else goes wrong (not that Jay didn’t work his fingers to the bone trying to get it to work everywhere). Anything in the core app has to work, and work on all sorts of old and ugly setups. It also means that the people (who are legion) that hate anything to do with blacklists don’t have to have anything to do with one: MT itself does some not very good comment stuff, and if you don’t mind the idea of blacklists you can add better stuff. Then, they could have had Jay’s Blacklist code to put into the core app, for free, but they have apparently decided to turn into a platform for third-party developers to work on, so now Jay will have MT-Blacklist for MT 3.0 as a potential source of donation income, to keep him interested in working on other MT stuff. Where’s the horrible failure in that again?
At any rate, it certainly wasn’t what you imply, that they were burning so much time supporting Atom that they didn’t have time for anything else. MT’s Atom support is basically XML::Atom on CPAN, and the changelog doesn’t look like it’s been a full time job, though it might hide some complexity.
Why am I going on so much about the MT asides in your Atom-bile-spew? Because by getting it so wrong, you probably lost all the people who know more about MT than they do about the Syndication Wars.
The Blogger thing? Might as well repeat this for the ten thousandth time. First, Blog*Spot and Blogger are separate things. Blog*Spot is hosting, so there’s no reason for you to have mentioned it at all while talking about syndication. Second, there really and truly aren’t any Pro users anymore: Pro has been discontinued (long, long ago). There are only *former* Pro users, from whom they have not taken anything away: they had not-very-good RSS 1.0 support (and when did supporting RSS 1.0 become so wonderful in this camp?), and if they want it they still do. Just like Atom, it uses a different root element, different elements for everything but title/link/description, but former Pro users who want it, warts and all, still have it. Blogger could have expanded that not-very-good support to all their users, and offered either a choice (Battle Of The Formats!) or both (Massive Confusion Over Minor Matters!), and had to spend development time on supporting both Atom and RSS 1.0 and support time on explaining what they were, why there were two, how to link to both, why you want two, or, they could do what they did, and decide to support the one that they thought looked like a better choice going forward. Them going with Atom rather than bad pseudo-RSS was a bit painful for a little while (I switched aggregators for a few weeks), and now it is only painful for Radio users, because Userland has chosen not to update Dave’s code that read Atom when it was Necho.
Features? From my perspective, the feature thing is pretty damn simple. In Atom, I know whether the title element is encoded HTML, or plain text. I can use pointy brackets in titles, without worrying about them being interpreted as HTML. In Atom, there is an element for a summary/description, and an element for content. In Atom, there is an element for the author’s name, not just an element for the author’s “give me more spam, please” email address. There’s a date modified, to help start figuring out a way to deal with posts that change.
Does that justify a new format, and months of architecture astronauts arguing over bizarre points of web service religion? No, of course not. But to get those things, we had no choice. There was a week or so last fall, when the RSS Advisory Board tried to stop the bleeding by fixing some of them, and it went exactly nowhere. Between the “frozen format” thing and all the baggage, there’s apparently no way to say what the title is, no way to say what descriptions are summaries and what descriptions are full item contents, and no way to have anything but a webMasterSpam element. It’s a shame, but apparently we are stuck with RSS 2.0 being exactly what it is, whatever that may be, for all time. Given the number of seconded motions left lying on the table, I’d have to say that RSS 1.0 is dead, too. Could we have fixed both of them by standardizing on alternate namespaced elements instead of the optional broken core elements? Not after the “funky” campaign, we couldn’t.
As to the support for syndicating playlists and sharing category trees, well, if you have a useful extension, and it can be supported in a useful way in desktop aggregators, beyond just what you would get anyway by including HTML in the description element, I know several aggregator authors well enough to suggest things, and they are all pretty eagerly looking for ways to distinguish their aggregators, and adding features like mad (I’m not sure what aggregators you’re looking at where you see stagnation, but I see Dare throwing new things into RSS Bandit all the time, sometimes something that he’s only seen in one feed), 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, so I’d think all you need is an implementable spec, and a few people publishing it, and you’re set. Seems to me like a pretty good time to be developing for RSS. Assuming you can get over Atom, realize that it isn’t going to stop just because you try to polarize things even more, and get on with doing things other than sweeping back the tide.
LikeLike
And then you had to get me all nostalgic for the earlier days of the Syndication Wars, when men were men and it was RSS v. RSS, with no furrin specs involved. I actually ran across a few pleasant reminders of some spots of fun, along my path to the RSS 2.0 Roadmap [1], which says “Subsequent work should happen in modules, using namespaces, and in completely new syndication formats, with new names.” and for that matter the RSS 0.93 spec [2], which said “Forking is OK, but please use a different name. Thanks.”
Also, you describe the RSS license as share-alike, though it’s actually Attribution-ShareAlike, which means that as long as you credit the original, you are completely and utterly free to create derivative works. It would take a pretty good lawyer to argue that the Roadmap text withdrew the license for the letters RS and S – I’m inclined to say that the license permits anyone and their uncle to copy the spec, change the ugly broken bits, and call it RSS 2.1. Not just one, but a thousand RSS 2.1s.
QED. There is absolutely, positively no room for an RSS supporter to object to an alternate syndication format which uses a name other than RSS. None. You don’t have a leg to stand on in any argument that Atom shouldn’t exist. Dave completely forgot to say “… as long as they are clearly unpopular and unsuccessful and unsupported.” Next argument, please.
You can argue that there are things RSS does that Atom doesn’t (though it will only help Atom, because they’ve been too lazy to actually track them down and throw in another link rel=”” or ten to cover everything), or you can catalog all the abandoned and semi-abandoned programs that don’t have Atom support or show any signs of getting it, or that parse XML in such a broken way that they can’t tolerate namespaces. You’ll need to ignore the online Atom-to-RSS converters, but it’ll still be more persuasive than arguing that creating a new syndication format was somehow wrong.
[1] http://blogs.law.harvard.edu/tech/rss#roadmap
[2] http://backend.userland.com/rss093#introduction
LikeLike
Isofarro…
Of course I want Google to offer syndication to their new accounts. I said the move was evil because they could have provided support for other formats, probably at no cost, but didn’t. I could be wrong, but I don’t think this was an engineering decision.
Regarding intellectual property, most companies require their employees to sign an agreement handing over the rights to anything they develop while in the company’s employ. This may not be the case with you, but it is usually the case. RSS is patent free and clearly marked with a creative commons license. As far as I know, maintenance by an IETF working group does not guarantee that a spec will be patent free. If there are public statements and/or discussion indicating how Atom will be licensed, can you please point to them? Thanks.
LikeLike
Isofarro and Jason…
Oh geez. Yes, I think the logical conclusion is support RSS if you want this market to survive. But no, I don’t believe I have sufficient mind-control power to cause people to relinquish their right to make up their own minds simply because I didn’t explicitly grant that right to them.
LikeLike
Phil…
Thanks for your posts. I really appreciate that you were specific about what Atom gives you that RSS doesn’t. I realize we can’t re-run history, but as I wrote above, I think it’s important to consider both the benefit and the cost of each new feature. If a format or application doesn’t have feature X, it may not be oversight or laziness, but the result of an informed decision by the software designer. For example, I know a lot of people say they like being able to differentiate the summary from the content body, but how many weblog writers actually make use of this? There’s a cost to the user, in that they have to fill out two fields instead of one. Movable Type has an extra field for this, but I never use it, it’s too much trouble. In fact, MT’s interface is so widget-laden that I avoid it whenever possible.
LikeLike
To be fair, a reasonable argument can be made for having a flexible format and letting the applications decide how much to expose or hide. But I don’t see why this couldn’t have been done with namespaces. IIRC, the funkiness campaign wasn’t about not using namespaces, it was about not using namespaces for standard fields that had non-namespaced equivalents.
LikeLike
(Apologies if this question seems off-topic. I assure you it is not.)
Andrew, are you planning on documenting the recent changes to your and Dave’s validator fork?
LikeLike
Mark, what recent changes? We’re running on a snapshot from the time we set the service up. At that time, I made a few modifications to allow 404 Not Found’s to be reported as such. I submitted a patch to Sam, which he committed to the tree. Afaik that change is no more or less documented than the rest of the codebase.
The only other change was to add a file that exposes the service in a RESTful way via mod_python. It’s a simple wrapper that does not take part in the validation logic and would only be of interest to people wanting to set up Web-based validators. Is this what you’re referring to?
LikeLike
No, not at all. I apologize for the intrusion, Andrew, I assumed you were in the loop on the most recent changes. I wonder who made them. Check your backyard; something stinks.
LikeLike
I had a fairly long wander through the funky thing last night, too (reading old flamewars at 3am: I so desperately need a life), and yes, with some caveats the nut of it was replacing core elements with extensions. However, the clearest description of how to be unfunky was “do RSS exactly as UserLand does” which means putting your full content escaped in description which is more incompatible with more things, and with things that can’t be changed, than the alternative.
If you’ll grant me the right to have both a summary and full content (which I need, because my RSS is *syndication*-syndicated, republished in a sidebar with the summary in a link’s title element, as well as read-syndicated, but an amazing number of people aren’t willing to grant me that right, just because they don’t need it themselves), then there are two possible approaches: description + a full-content element, or a summary element + description-as-content. Out of scope and beyond our control, RSS 1.0 leans toward description + a full-content element, so most modern, actively developed aggregators already support that. Out of scope and beyond our control, things written back in the RSS 0.91 time expect description to be a plain text description of less than 500 words. So doing sumsum:summary + description == content means that I expect everyone to rewrite their stuff to support my feed, and if they don’t some of them break and break hard, while description + content:encoded means I would like those few people who haven’t yet to rewrite their stuff to support both my feed and RSS 1.0 feeds as best they can, but if they don’t they get a slightly less full experience.
I don’t insist that you do a separate handwritten summary, and if you don’t I don’t much want you to fake one with a few words of HTML-stripped excerpt (if I need that on the client end, I’ll make it myself), all I want is to be given permission to do so myself. Beyond that permission, I’d really like to not have to give Radio users just the excerpt (they must find it odd that I agitate for full-content feeds, but (last I saw) only seem to give them an excerpt), but that part’s not up to me.
And yes, it was Dave who taught me that you don’t break the old unmaintained stuff to make things easier for new, actively supported stuff, during the RSS 2.0 namespace discussion, and it was a very good lesson for which I’m very grateful. I wish he would have taken it to heart for 0.92, but that’s water under the bridge. In the here-and-now, my feed is funky (a funkiness that cost me dearly in the link economy of weblogs) because doing otherwise would hurt people who can’t fix the hurt.
So, the point I think I intended to start with is that one of the things that Atom will give me is the feeling that I am unambiguously doing the right thing, not breaking anyone and enabling everyone to have just the data they need. RSS? Every time I look at my feed, or think about Radio, I remember that I was banished because of it.
OT, about the MT input interface. If you go down to the very bottom of the page, there’s a link to “Customize the display of this page.” Click that, choose “Custom” and you can include just the fields and widgets that you will ever actually use. It’s a big improvement, though not quite as nice as the Mozilla-only, built-in-XUL bookmarklet form I made myself, where the three I use (entry, excerpt, extended) share a space, with the inactive two being hidden with only a visible header that you click to open one and close the other two. I really should try to port it back to the HTML form (and finish it, since it was supposed to color the header for entry and excerpt red until they have at least one character, to remind me that I require both). It’s so cute I still just play with it sometimes.
And, one other benefit of Atom that I forgot because I don’t use it directly myself: support for relative URLs. I know people who only provide an excerpt in their RSS because they use relative links, and RSS doesn’t say how to interpret them, so they get interpreted differently in different clients. So there’s another thing that has actively harmed me about RSS (Scott Andrew, the brilliant musician and web developer, only recently went back to a full content feed, after doing only plain text excerpts for a long time for this very reason) which Atom will solve. There was a little bit of activity about relative URLs from the RSS Advisory Board last August, but it seems to have died without any result that Google can see.
LikeLike
http://backend.userland.com/davesRss2PoliticalFaq#questionWhatDoesFunkyMeanInTheContextOfRss20
LikeLike
I haven’t made any changes to the validator. I’m in Germany, not programming.
LikeLike
OK, the mystery deepens. Both primary developers of the scripting.com validator fork claim ignorance of the most sweeping change their fork’s history. Is it possible your server has been hacked? Because your validator is behaving *much* differently today than it did the last time I checked it (which was 3 months ago, when you first forked it).
LikeLike
Is it fair to assume that at some point you’re going to tell us what the problem is Mark?
LikeLike
Andrew: For me, any tool that supports Atom, RSS 1.0, and RSS 2.0 deserves praise for its syndication support. MT falls into that category.
Isofarro: The “funky feeds” issue with Movable Type is a legitimate complaint.
Movable Type does a good job on the whole of being syndication protocol agnostic, but its default RSS 2.0 template deviates from most RSS 2.0-generating tools by using namespace elements and dropping core elements that serve the same purpose (for instance, dropping pubDate and using dc:Date).
While the feeds still are valid RSS 2.0, MT’s 2.0 feeds are less functional than most — any tool that supports the core elements of RSS 2.0 but doesn’t support Dublin Core yet will have no date support.
I suspect that this design design was made because early versions of MT couldn’t create proper timezone offsets for RSS 2.0’s date format (they contained a colon). That has been fixed as of the current version, 2.661, with the no_colon attribute in the MTBlogTimeZone template tag.
Another reason the “funky feeds” issue matters is because the Feed Validator recommends that MT users adopt a funky RSS 2.0 template. They actually guide MT users to exclude pubDate in favor of dc:Date, which is ironic considering that Atom’s own date element — modified — cannot be replaced by dc:date. Mark and Sam’s validator recommends something for RSS 2.0 they won’t allow in Atom.
http://feeds.archive.org/validator/docs/howto/MovableType.html
LikeLike
Woohoo! It’s like the funky guessing game all over again!
Oh, wait. I hated that in the way that involves splitting a couple of cords of wood, to avoid splitting my computer instead.
The only thing I see is that it says my Atom feed is invalid [1] because of the one element of funk in it, a dc:subject. No idea whether that was something in the base at the time, or broken from the first, or newly broken.
[1] http://rss.scripting.com/?url=http%3A%2F%2Fphilringnalda.com%2Findex.atom
LikeLike
> While the feeds still are valid RSS 2.0
Are you sure? Check your backyard; something stinks.
LikeLike
Rogers, Dave praised that template when I first released it.
http://archive.scripting.com/2002/09/26#When:7:01:56AM
It didn’t become “funky” until Movable Type adopted it.
And now it’s become invalid as well (if you believe Dave’s forked validator).
LikeLike
Mark: Who cares what Dave said about your template two years ago? Stop holding on to all of these old Scripting News links so you can spring these “Perry Mason” moments on everybody.
Whether you call it “funky” or “less functional,” the fact remains that telling MT users to drop pubDate for dc:Date in an RSS 2.0 feed is bad advice.
I also question whether the Feed Validator should be making a suggestion that doesn’t impact validity or non-validity at all — a criticism I would’ve shared with you if the Feed Validator site let me know where you want to receive feedback.
LikeLike
Andrew: If UserLand’s RSS validator and the Feed Validator use the same code, why does my example MT RSS 2.0 feed validate in one and not the other? There appears to be a bug in UserLand’s validator that doesn’t recognize the dc namespace.
LikeLike
Example feed:
http://www.cadenhead.org/hype/index.xml
LikeLike
Rogers, are there many things in that position? I would have guessed that since RSS 2.0 added item-level pubDate in the fall of 2002 (or, 0.93 added them in the spring of 2001, depending on whether you count it or not) and RSS 1.0 added item-level dc:date in the winter of 2000, that there would be more things which don’t know about pubDate than don’t know about dc:date.
Or do you mean the unfortunate things that follow a completely different code path for different formats, rather than just normalizing whatever they find, irrespective of the root element’s name?
Feedvalidator feedback:
http://lists.sourceforge.net/lists/listinfo/feedvalidator-users
The fact that I’d never noticed it was only linked on error pages probably says bad things about how much time I spend on the error pages 😉
LikeLike
Rogers: “The “funky feeds” issue with Movable Type is a legitimate complaint.”
But not legitimate enough for Dave Winer to be up-front about it from the beginning, it seems. Its interesting the claim was made, by Dave Winer, on the 8th June 2003 – with no details at all. A week later, a tiny bit more detail – http://backend.userland.com/2003/06/14#a227 – still nothing constructive at all. Conversation in the comments – http://backend.userland.com/comments?u=backend&p=227&link=http%3A%2F%2Fbackend.userland.com%2F2003%2F06%2F14%23a227 – continue until the 21st June, still no explanation as to what the problem really is. Read through the comments, notice how much ducking and weaving instead of coming straight out and answer the question. Eventually, June 30th – http://backend.userland.com/davesRss2PoliticalFaq#questionWhatDoesFunkyMeanInTheContextOfRss20 .
22 days of FUD, dodging and weaving. By that time, a lot of people had left the building and were working on Atom instead. That was a major factor in the push towards the – any bus that doesn’t have Dave Winer driving or conducting – which of course precipitated Atom.
Sam Ruby restarted the RSS profile project on the 16th June 2003. Right in the middle of the funky feed debacle – that one small endeavour of setting up a wiki was the beginning of Atom. It became Atom because it focused the efforts of people to define a well-formed blog entry, and consensus / mutual agreement took it further forward. If anything, the wiki reinvigorated interest and thought into syndication – it was a constructive. A complete break from the funky feed debacle.
I guess during those discussions over a well-formed blog entry, a sense of community was built without RSS2.0.
Funky feeds served to ignited the need to get away from vendor-controlled / personality-dominated format. It was the final straw for many people that pushed a lot of developers away from RSS2.0. By the time Dave Winer finally decided to come clean with funky feeds, developers mindshare was elsewhere.
Now, as to whether funky feeds _was_ a legitimate concern, http://diveintomark.org/archives/2003/06/26/will_the_real_rss_validator_please_stand_up seems to document a complete and total about face from Dave Winer. The issues raised by funky feeds – vendor dependance, ambigious specification, became the problem Atom set out to solve. Added to that were the problems in RSS2.0 that were brough up previously and remained unresolved – typically as a result of StopEnergy.
The anger and the uncertainly generated by Dave Winer’s funky feed campaign ended up channeled constructively into Atom. And because of the sense of community already existing around Atom, two very interesting things happened:
1.) People began switching off from Dave Winer – notice the non-existant level of discussion around the “Peace proposal”. I think the only Atom-based response was from Sam Ruby pointing the way to IETF.
2.) The StopEnergy campaigns against Atom have taken on some serious intensity – but this time its failing to grind Atom to a halt. The focus of Atom developers is impressive, considering the long flamewars that erupted over the great divide of RSS1.0 and RSS2.0.
There’s a community around Atom now. Its time the RSS2.0 camp recognised that, and quit this FUD nonsense.
LikeLike
Returning to the topic of the original post, regarding features for the end user. Why do you think so many developers support Atom? It’s not just down to a personality thing with Dave (though he has managed to get up an awful lot of noses), and for the majority of people it’s not about money. It’s because the RSS environment wasn’t conducive to forward motion. RSS 2.0 is lacking in fundamental ways (like there being a way to tell whether content is HTML). RSS 1.0 had technological advantages, but has suffered collateral damage from the hype of “simple” syndication. The only way out of the quagmire was a new system.
I think the healthiest way of looking at the situation is that the RSS specs have been prototypes. Userland RSS has been useful in identifying the minimum that could possibly work for syndication. RSS 1.0 has been useful for experimenting with extensibility, to what extent developers are willing to support innovation*.
Both approaches have successes and failures. We can learn from them and move on.
* significant developments have appeared outside of the syndication domain in other RDF applications, which says a lot about how the syndication field has been hampered by the marketing of “simple”
LikeLike
There was, and is, a group of people that hold to the philosophy, “If only everybody changed they’re formats to RDF (aka RSS 1.0, aka “Rich Site Summary”), then tools would spring up to bring the user’s wonderful delights!!”.
But with the success of RSS 2.0 over the past 2 years, especially over the past year, a lot of these same Pied Pipers along with additional Pied Pipers raised the claim, “Atom will be the one and only format to replace RSS 1.0 and RSS 2.0, then all the developers will support Atom instead of RSS 1.0 and RSS 2.0 and tools will spring up to bring the user’s wonderful delights!!!”
And those who are these Pied Pipers are unanimously in favor of the approach, wonder of wonders!
I’ve pretty much decided that any group that says or implies that what Mark Pilgrim has to say, on these subjects, is anything close to “honorable and wisdom” is decidedly bogus.
:
So.. is there a website set up to discuss whether utilizing BitTorrent or similar to develop a mini-grid of changes.xml of benefit??? If so, where and when?? (And I don’t even care if Mark Pilgrim participates or not, but would care a lot if his words are given much credence.)
If not, how’s come? This here FUD from Atomites?
LikeLike
[Out of sequence here]
Isofarro – once again, very well put.
LikeLike
Rogers to Mark: “Who cares what Dave said about your template two years ago?”
Isn’t the point of freezing the RSS2.0 specification supposed to allow for stability? If RSS2.0 has been frozen all this time, then a valid – and praised template – two years ago should still be valid – and praised.
This particular point was another Atom cornerstone for a specification that is cleanly and thoroughly specified – not subject to the changing opinions of an individual.
LikeLike
Ah yes!
And funny how Danny Ayers raises up to confirm my point, at just this time!! Thanks!
I would suggest that the time is ripe for a few to actually move on.
Leave the Atomites behind, since as was mentioned by one such, there was no movement towards a peaceful resolution from the Atomites. So let’s leave them and the RD-EFF’rs to develop their own Rube Goldberg spec, and perhaps they will develop some things which are useful to folks who appreciate the simplicity of R-simplicity-Syndication 2.
As opposed to the richness (of monetary and ego variety) of Rich SS 1…
I would suggest, not TO anyone what they should do with their time and energies.. But just suggest that the time is, imo/o, ripe for progress in developing an xxx 3.0…
I’d also suggest that Google isn’t (nor SixApart, likely) gonna go much for xxx 3.0, but alas…
LikeLike
Well,
I don’t know “Isofarro”, other than seeing name on Atomites mailing list.
I would suggest that one of the primary selling points, this time last year, of Atom was that all the developers would be involved with it, so they’d all adopt Atom in place of RSS 2.
How’d that work out?? That being one of the cornerstones of Atom, originally.
One of the other cornerstones was using the validator provided by Mark Pilgrim and Sam Ruby. With Mark Pilgrim being involved, that necessarily implies a validator that is EXTREMELY susceptible to the errant opinions of an individual.
LikeLike
Rodgers, thanks for pointing that out. We’re running a snapshot of the code, which in the meantime has moved. That looks like a bug to me too. I will investigate.
LikeLike
I know, I know, don’t feed trolls, but: feedvalidator.org gets changed by an automatic push from the Sourceforge project, so you can see all the evil that Mark’s been up to lately by just looking at the CVS checkins from f8dy. I couldn’t find any, myself.
LikeLike
No offense, Danny, but I think RSS 1.0 suffers from the needless complexity of RDF and multiple namespaces. I know that’s heresy to some people, but I don’t think you get enough benefit from the hassle.
“If RSS2.0 has been frozen all this time, then a valid – and praised template – two years ago should still be valid – and praised.”
Perhaps Mark’s template was praised because Dave didn’t realize at first glance that core elements had been dumped for namespace elements. It wouldn’t be the first time that a weblogger changed his mind.
Personally, though, I could care less what person X said about format Y on date Z. Let’s talk about where we are now and where we want to go.
For me, I’m still waiting on the selling point of why Atom deserves to be supported over RSS. I can see why implementors might prefer it to RSS because the format is more rigidly specified, and I recognize that a lot of gung-ho Atom evangelists are dying to stick it to Dave Winer. But those are both non-issues to me — dozens of developers support RSS 2.0; hundreds of sites, and thousands of people use the format every day; and the personal stuff is a waste of time.
LikeLike
Mr. Ringnalda,
“I know, I know, don’t feed trolls,”…
That could, perhaps, be in reference to myself, since I get that a lot. (However, my pseudonym is Trouble, which is not synonomous with troll…;-) That there are bugs in validators and checkins from somebody (identified as “f8dy”…?!?) are, to me, somewhat part and parcel of the nature of software dev… Development can be a sausage-factory-haphazard-like process, frequently! Some bigger deals than others, I suppose.. but not exactly something to make a Federal Case about. My comments re: Mark Pilgrim do not stem from any one particular event, and this article is but one example:
Normalizing Syndicated Feed Content
http://www.xml.com/pub/a/2004/04/07/dive.html
“If you haven’t torn all of your hair out by now, here are some additional links that are required reading for anyone silly enough to want to write a syndication consumer:”
Fine typical-semi-tongue-in-cheek remark, which somewhat also applies to anyone writing a syndication producer. However, the facts are otherwise. Mark Pilgrim would imply that software developers should have the same understanding of these “grand format wars”: Which is that Dave Winer and anything he wants to see in a format standard was, is, and forever always will be.. necessarily bad.
The fact is that a software developer can, and sure should be able to, look at a clearly-defined spec and come up with something pretty close to working. I am not against ALL the principles of Atom, and this is one-a the good principles, to me.
However, Mark Pilgrim would rather that wasn’t so, and you really do need to see the primary advantage that Mark sees in it, being that Dave Winer had nothing to do with it. That way you can see the relatively minor advances of Atom as being as so, So, SOOO valuable.. the way Mark Pilgrim sees them (which is over-sized).
Similar to how Dave Winer sometimes, like frequently, oversizes the inherent values of blogs, imo/o (in my opinion and/or/..observation). Most of this talk about how “all the developers” are doing Atom is in relation to blog-software developers.
I guess the developers at all the places (like Nokia, Yahoo, Disney, papers, gov, etc.. to be redundant, yet once again).. well these developers are of no account, apparently to some. They don’t seem to get counted somehow, in these “all the developers support this..” kinds of statements… (Perhaps because they’re more concerned with producing useful stuff and don’t have the time?)
I see very few willing to waste the time on these “wars” and/or/nor “debates”. The one like we’re having a “conversation” about now.. for instance. I never said that Ben Hammersley didn’t capture some of the flavor of these “semi-ridiculous” goings on…;-D (But to answer that question of Danny Ayers at Workbench, it’s not just a matter of the conflicts-of-interest should have been disclosed, but that they should have been averted if one is going to publish something as news rather than op-ed. BIG difference in context. Btw, is xml.com considered news or op-ed???)
Anyhoo, I guess I’m done trawling for today.
Having just read Rogers’ comments, sorry so few (and even Rogers) seem interested in forking all this stuff back to RSS 2 and RDF/Atom, pretty much the way it is anyway.
LikeLike
JamesJayTrouble, who ever you are, I want to give you a big hug next time I see you!
(I’ve subscribed to your feed.)
Re XML.Com as an op-ed site, I asked that very question in response to a Pilgrim piece that developed a theory but left out a crucial piece of info that contradicted the theory, one that Pilgrim surely knew. Edd Dumbill, editor of XML.Com, responded basically by saying that they encourage their authors to write fiction, facts aren’t particularly important, it’s more about moods and nuance (I’m paraphrasing based on my recollection, those probably aren’t the exact words he used).
I decided to accept that, and assume that XML.Com will take care of informing their readers of their editorial policy, although I’m pretty sure they haven’t. I can’t take on solving all the world’s problems.
And Rogers, I love the term “Perry Mason Moment.” That pretty much sums up Pilgrim’s style. Geez, you’d think I committed a crime by saying something nice about him two years ago. No good deed goes unpunished. ;->
LikeLike
Dave, you should have had a look at that guy’s site before you subscribed. He updates his blog less often than Ben Trott, who at least has the excuse of being busy doing something useful.
LikeLike
Thought I was done trawlin, and put up the hip-huggers a li’l too soon…;-D Trouble sleepin…;-)-;
@Dave Winer,
Mice-like folks occasionally have a point, tho anonymice are a bit squirrely for my taste.. and I think hugs may be a little over-exhuberant! A hug with me will do ya more harm than good anyhoo. A hug or two from some MicroSofties would be another matter, altogether..
I was also trash-talking you too, Dave, when I said “But just suggest that the time is, imo/o, ripe for progress in developing an xxx 3.0…”
I mis-“spoke” in last post above, was gonna correct it but then didn’t..
~~~~~~~~~~~~~~~~~~~~~~~
Eh.. crap! Talk about bad marketing!!
Meant to say few “seem interested in forking all this stuff” FORWARD to RDF/Atom and to the PRESENT with RSS 2/xxx 3. Seems a natural split has occurred along those lines anyway, just not a WHOLE lotta forward progress, imo/o.
Although I forgot to say that Rogers’ comment is probably UNDERstated, unless he meant 100,000’s of people (per hour or something (‘d be my guess, anyway)).
~~~~~~~~~~~~~~~~~~~
So, Mr. Winer, while I’m glad RSS 2 has been fairly stable and SO widely adopted.. I’m still not seeing the forward/current/whatever Direction of RSS 2 towards xxx 3…
It may be too difficult for Sam Ruby and Tim Bray to extricate themselves from their constituency, I dunno. I also don’t know, but think there are mebbe, a few people from the ScriptMeridian community that may be interested in hearing some-things specifically from the RSS 2 BOD, either separately or better still, as a group on what the next step(s) might be (or “emerge”, if you will).
(?)
There are, perhaps, times when these things need to be discussed privately before discussing in public, btw, in my experience. I learned this from a slide show of Dr. Roy Fielding, some time back.
@”it” at there… Thank you for the honor of comparing me to Ben Trott. However the comparison suffers from the fact that we do different things altogether. Having some common sense about blogging is not a great amount to have in common…;-D
Nite ol.. korrect?
;-D
LikeLike
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. ;->
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.
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.
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.
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.
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.
LikeLike
Can I go first? 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. I need a content model for the title element: plain text or HTML? One escaping or two?
LikeLike
You can go first, but you haven’t stumped the spec. Sorry. 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. You could have a great time Phil, and if what you did truly couldn’t have been done with RSS 2.0 titles I would sing your praises far and wide.
Now I have to get on a train to Cologne and then from there to Amsterdam. It’s a bright sunny day here in Bonn, overlooking the Rhine River.
Auf wiedersen!
LikeLike
Guess I better work on my question-asking technique. All I want is to be able to have titles like “How to use the <strong> tag” without worrying about having aggregators strip it out (as some do), or think I wanted to turn everything after that bold (as some do), or display it as <strong> (as some do). That’s all I meant I need, is for the spec to say whether “HTML is allowed” (which really means, “when an XML parser has decoded entities once, as part of parsing, should the result be put in an HTML page as-is, or escaped once?”). I sure hope I don’t need a non-core element for that.
LikeLike
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. That RDF/XML syntax can be simple is evinced by Dave’s comment about RSS 0.9 [1] in his (*cough*) history : “The only thing about it that was RDF was the header, otherwise it was plain garden-variety XML.”. He’s wrong, it’s all absolutely correct RDF/XML. Similar simple suggestions were submitted to him when he was talking about RSS 2.0, which he flat rejected.
I personally think the benefit of XML namespaces and the RDF model are very much worth the hassle – they enable direct interop between systems and application of the same tools on data from different domains. I reckon it’s a shame that Atom didn’t adopt RDF/XML syntax, but all being well the definition will be web-friendly enough to allow the RDF model to be used with Atom data. (btw, this is possible but not altogether straightforward with RSS 2.0, largely because of the guid – the web already has globally unique identifiers (URIs), allowing arbitrary strings just throws away a huge amount of interop potential).
flogging
[1] http://www.purplepages.ie/RSS/netscape/rss0.90.html
LikeLike
heh – all my markup was stripped, but I think the message is still deducable…
LikeLike