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.
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.