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...
You can't back that up with anything I ever said or "claimed." I and my company disclaimed ownership of everything, even the copyright on the spec I wrote.
1. There are only really 4 versions of RSS, and Winer wrote two of them. There were 3 different groups involved, which was the problem - the problem isn't having newer versions.
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').
There may ideally be only 4 versions of RSS, but Winer was responsible for 6 of them :)
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.
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.
urgh.. I have no idea how this turned into me defending Winer since I only wanted to respond to the Pilgrim posts which were FUD (the two examples you originally posted).
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)
That's not all that fair on Mark (who yes, can be just as bad) - there was a desire to fix things within RSS 2.0, but Winer refused to update the spec to fix things like the Reuters problem. Atom seemed like the only way to move things forward at the time...
Okay why does this get moderated up to 22 points if Hacker News is such a respectful place.
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.
ATTN: realize that the StackOverflow question dates back to 2008.
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.
Beginning to read that story, the only Atom I could think of was the processor... which I quickly realized was not what they were talking about. It seems this is a case of failing to see your post like your readers will, without some preexisting context...
I posted it here because the author wanted to post it on my blog, and I didn't want to host yet another of these angst-fests about who was right or wrong about stuff that mostly never actually happened.
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.
>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.
* shrug * it's been working flawlessly for me everywhere I've used it, and it makes the sign-up process easier. The one complaint (and it's a big one) is that it makes it very hard to have multiple OpenID accounts on a site. You have to log out of your "current" one, and into the one you want.
I can see no reason this can't be changed with a plugin, but it's still a PITA.
Ever tried to include an ampersand in an entry title in an RSS feed? The RSS 2.0 spec still doesn't specify if the title should be HTML encoded or not, and the implementations tend to disagree as a result. This is why my apps always produce Atom, never 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.
How do you still not understand this, 7 years later? The RSS specs you defined do not allow the author to specify the type of text contained within an element — the processor has to guess whether it was plain text or HTML based on how many levels of escaping were applied.
So you can happily use Atom, which allows you to say whether your title has markup or not.
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.
Yes, you were (in hindsight) right in standing fast against correcting these problems in RSS 2.0, no-one would have been satisfied with the result.
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.
So there's an inconsistency betw your post and this comment.
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.
XML is extensible, and this is why. There isn't any good reason to encode markup as text content, only for the recipient to unencode it and then run its markup parser a second time. If you want to use elements from the XHTML vocabulary inside an RSS document, the right thing is to just do it, like so:
<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 &).
"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.
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.
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...