Why Atom was created
isolani.co.uk
isolani.co.uk
Please stop producing any flavor of RSS. Absolutely stop producing the same content in multiple formats, that's just inane. I am not not aware of any software not written by and for Dave that cannot parse Atom (iTunes does handle Atom podcast feeds, but they must be valid to work). If you really care about ancient clients, run your Atom feeds through Feedburner, they can take care of it for you: http://www.google.com/support/feedburner/bin/answer.py?hl=en...
All these technologies are yours, except those that Dave Winer claims ownership of. Attempt no landing there.
2. You could say the same of Mark Pilgrim's social problems. He is very difficult to get along with, is very arrogant and lead a crusade against Winer for years. He on one hand argued that RSS was fragmented and incompatible, but his solution to that was to start yet another syndication format.
You are forgetting that what made syndication popular was the simplicity of RSS. There were other formats before it, and there have been formats since - but the ease of implementation and simplicity of RSS ushered in a whole new era of services and nothing less than blogging itself, podcasting and all the services since that have built on that foundation (ie. 'the social web').
Mark may be an asshole, but he's nearly always correct (save for his recent Apple II fixation), and he follows up instead of trying to edit his mistakes from the record. He has a lot of company in hating Winer, basically everyone Dave's ever worked on anything with.
Here's some examples of classic Dave: http://www.metafilter.com/26701/ http://www.metafilter.com/33699/ http://workbench.cadenhead.org/news/2881/ (note that rcade, the author of the last link, was Dave's sole defender in the earlier ones). Here's some freshly curated ridiculousness: http://eyeonwiner.org/ http://davewinerscrazytrain.tumblr.com/
RSS is no simpler than Atom, not even when used naïvely — it's just easier to break. It was successful because Winer was at one time successful, but after he managed to attack and alienate everyone else in the field, they moved on and started over with a clean slate.
You don't have to convince me that either of these guys are nutters - I know it all too well.
My point is that there are two sides to this story (well, 4 really) - that RSS popularized feeds and that in the past 10 years despite all the effort nothing has been made easier for devs, if anything it is even more complicated (esp with the namespace extensions from iTunes)
I don't know who this guy is and what axes he has to grind (and the 22 people who think this is an important comment), but RSS is a huge success, anything but a "clusterfuck."
And River2 fully supports Atom. That's just outrageous that you say my software doesn't support it.
Also, iTunes has supported Atom feeds since iTunes 6 (October 2005) if not earlier so the linked stackoverflow comment was wrong even as it was posted, two years ago. If iTunes refuses to consume your Atom feed, it's likely because your feed is broken and doesn't validate.
>One of Dave Winer's many handles. (I can never remember my password so I create a different account on every machine I use and stay logged in. Sorry.)
Jeez, give OpenID a try, or use a password manager. Both of which are also significantly more secure options than adding more passwords to your own memory / relying on stale cookies.
I can see no reason this can't be changed with a plugin, but it's still a PITA.
I once called Mark Pilgrim an asshole, that was the extent of my crime against him. He had it coming, he was being an asshole. But if I had known it would lead to the kind of jihad he led, I would have let it go.
Anyway, to answer your question -- yes this is me.
Edit: Here's an article that illustrates the problem: http://www.xn--8ws00zhy3a.com/blog/2006/06/encoding-rss-titl... - this kind of unresolved ambiguity in the RSS spec is one of the main reasons Atom was needed.
It says it very plainly in the RSS 2.0 spec.
"RSS is a dialect of XML. All RSS files must conform to the XML 1.0 specification, as published on the World Wide Web Consortium (W3C) website."
Pretty sure the W3C tells you how to encode an ampersand in XML. If not, your quarrel is with them, not RSS.
It's a serious point. The complaint isn't even a nitpick, it's covered. It's like saying every program has to define arithmetic if it's going to add two numbers together. No, it doesn't. That's the job of the processor.
<rss:title>An <html:em>Emphasized</html:em> Title & Stuff</rss:title>
and when you need to cater to some widely-used aggregator that's too broken to handle this, the right thing is not to start breaking what you give everyone else, but to transcode this on the fly to whatever brain-damaged markup that particular aggregator version happened to be able to cope with (probably drop the namespace prefix and use CDATA, or failing that just strip all open/close tags and re-encode each &).What alternative was there? Would you have been happy with just adding an attribute to title? What if people didn't use it? What would you have solved then?
And would you have been happy with jsut that one change? THen why is Atom so different from RSS? Why did the name for <item> change to <entry>? I don't recall anyone offering a reason why item was such a bad name.
Another question -- when was the last time you saw a title that had markup in it? I've never seen one, and my code has parsed a lot of feeds over a lot of years. Perhaps people followed the doctor's advice. If it hurts when you do it, don't do it.
Try a thought experiment, suppose we had changed the spec. What else would you have wanted to change? Juding from the Atom spec, quite a bit. How many RSS's would we have then?
And who would this have been good for? We all would have had to stop making RSS apps and convene and working group and hash it all out. So instead of having 50 people on the Atom mail list, we would have had 800 people on the "Let's Completely Redesign RSS" mail list.
Did you observe what happened with SOAP when the WG was formed? And you think that would have been worth it, just to get an attribute on the title element?
You have to look at the actual problems people are having writing apps.
That you guys could only find this and the number-of-enclosures issue says that RSS 2.0 is pretty damned good. And it works for what it was designed to do. And things we didn't expect when it was developed. That's the sign of "pretty good" technology. No it's not perfect. Anything you ship will not be. Atom is not perfect either.
It's amazing to me that after 7 years, and the lack of impact that Atom has had, that you still don't get this. I would never have said it this way in normal discourse, but I think you should have the experience of someone lecturing you in public, as you have lectured me.
Atom started around the discussion of "An Anatomy of a Well Formed Blog Entry", not any specification text. We didn't start with a copy of RSS 2.0 and XML/RPC and rewrite bits and pieces until it became Atom. The Atom community went further back than that, we examined how RSS was being used at that time, and considered how it might be used in the future, and defined several use cases or problem statements, and built up a specification format based on that. As far as I remember, we never started with the RSS 2.0 spec text.
The Atom Syndication fomat (the XML part) and the Atom Publishing format (the REST part) started as one and then later ran separately in parallel. Both fed requirements into each other.
In RSS2.0 the item element was always inside a channel, so there was always a parent context of it's meaning beyond it's namespaced definition. With Atom publishing format, we have blog entries as stand alone documents outside of a feed (so they can be created, retrieved, and updated as a single document). In that context, a top-level element name of entry is an improvement over item. And it was important to us to use the same vocabulary across both the syndication and publishing formats so the element became entry on both.
Atom started from a clean slate, as you point out, there was going to be no way of fixing those problems with the RSS2.0 specification without significantly breaking existing implementations and backwards compatibility, and if somehow these were avoided, the RSS2.0 specification would probably have ended up in an absolute mess.
Maybe you'd like to review your post and see which parts you really believe and which parts are just hyperbole.
Seems like a good time to figure out what actually happened there, as opposed to just re-reciting the same tired myths yet again.
That's what I liked about the comment on Stack Overflow. He learned something from the way things turned out. This comment also shows that you've learned something, but your post is the same old same old.
"The main problem with the RSS title element is how to deal with the characters & and <. They have to be encoded at least once as a requirement of XML, but for those aggregators that treat titles as HTML, a second level of encoding may be expected in order to comply with HTML."
They have to be encoded at least once but do you do it once, or twice? That's the ambiguity.
For example, here's an aggregator of a bunch of East Village blogs and news sites.
The feed titles are the text of the links. You don't see any encoding errors. The blogs use a wide variety of tools to create their feeds. Some are RSS 2.0, some are Atom 1.0. There might even be some of the older formats in there. They always seem to get the titles right. I decode them once.
There are generally more problems with descriptions as weird Windows characters pass through their CMSes, and we have to do something with them on our end. Over time my software has gotten pretty good at dealing with these.
So when someone raises this "issue" I seem it as more political than pragmatic.