Diego:

Thanks for taking the time to write an intelligently worded piece. I suggested something similar, with more coarse language (but not rude) here:

http://www.houseofwarwick.com/2003/07/06.html

about 5 months ago. We need an independent group to control the flow. Right now, very intelligent people are taking ideas and swimming like salmon trying to spawn. The all work independently, but unknowingly to the same purpose.

If you don't like the API, change it. Just don't change the feed format and make the whole world bend for no reason.

Thanks,

Steve

It's simple. We want to use the Atom format for our feeds at Blogger. There are some reasons for that. I don't mind if it's based on RSS 2.0 or not.

Thanks for the comment, Evan! From what you are saying I understand the following:

1) Blogger wants to use Atom's format, regardless of whether it's RSS 2 or Atom's

2) Hence, Blogger's interest is less on the format itself than in adopting a single "package" under the name Atom, or whatever name Atom ends up with. (possibly to simplify the API usage etc?).

If Blogger doesn't mind about whether the underlying Atom feed format is RSS or not, then would it be possible for Blogger to say that RSS would be preferable?

That is, all things being equal, going with RSS would greatly simplify things for aggregator developers and others (including users). I stress that this would be stated as Blogger's preference, since there would have to be agreement from others (most notably Six Apart) but if Blogger doesn't mind then it's one less hurdle for RSS adoption within Atom (even if it's with some clarifications made to the spec to fix some small ambiguities--and Dave has made it clear that this is doable given the new copyright status of the spec, etc).

Well... while I enjoyed your previous post about "The Power Of Simplicity", I have to admit that after taking a closer look at the Atom spec, I would say that it fits the bill quite nicely :)

Two concrete examples:

Thread handling. RSS 2.0 has no normalize way to do it. And while namespace extension is always a possibility, it's mostly a dead end as everybody and their dog roll their own solution. Because Atom uses the same "link rel" semantic as HTML, this problem is mostly solved with Atom. This is potentially a huge win :)

Attachments. While RSS 2.0 has some fuzy notion of "enclosures", Atom provide a clear and simple content element. Problem solved :)

And not having to deal with Mr Winer's hubris is an additional bonus ;)

So... as far as having to choose a syndication format to solve concrete problem, Atom is very attractive indeed :)

Zoe, thanks for the comment.

Both the "thread" and "attachment" issues are solvable by namespaces (in the case of attachments, that would imply that enclosures are not enough). The problem of "everybody and their dog [implementing it differently]" would be solved, precisely, by a possible Atom+RSS combination defining these namespaces clearly.

So I still don't see what Atom does that RSS 2.0 can't do.

And regarding your comment about Dave: let's not get sidetracked by personal opinions about other people (that in many cases we don't even know in person--only "electronically"); please, let's keep the discussion focused on the format(s) rather than go down a road that does not add anything useful or constructive to it.

"by a possible Atom+RSS combination defining these namespaces clearly."

I don't see how this is going to help one way or another. RSS 2.0 doesn't support neither threads, nor proper attachments.

"So I still don't see what Atom does that RSS 2.0 can't do."

Thread and attachments for one :)

"Mr W. "

This was I joke. Therefore the smiley :)

My only point is that, as far as solving concrete problem that I need to address today, Atom looks like having more potential than RSS 2.0.

This is not an ideological position. Just a pragmatic one. That's it.

To my understanding, the "RSS 2.0 version at Berkman" is the official version of RSS 2.0. Any other version is "something else" and "competition" and potentially "funky".

Even if "Atom" takes the RSS 2.0 spec and reissues it as the "Atom R*S" spec, it will still "be" RSS but not "be" officially RSS.

How do you see that issue being resolved?

Zoe,

I don't get what you're saying about the namespaces not doing the job (besides, you mentioned namespaces as a solution yourself in your previous comment!). The RSS 2.0 spec clearly states (http://blogs.law.harvard.edu/tech/rss#extendingRss) "developers wanted to extend [RSS can do it] using modules defined in namespaces, as specified by the W3C."

As long as the namespace is not redefining core elements, things should be ok. I see no problem in defining a namespace for threading that extends an entry and leaves non-aware RSS readers in peace. Ditto for attachments (assuming there's something that enclusores can't do for them).

Additionally, the 0.2 draft spec of Atom makes no mention of threading or recursion.

I can see that you *didn't* say that namespaces wouldn't work, you just said that RSS 2.0 doesn't support those features, but you didn't provide an example of why RSS 2, using namespaces as I mentioned, would not support threads/attachments or whatever else if they were properly defined.

If the same result can be obtained by doing a simple extension to an existing spec, why break things and create something new, at this point, considering what I outlined in the entry? The pragmatic thing to do at this stage seems to me to extend or refine possibly ambiguous definitions of RSS when necessary.

Just my opinion. :)

Hi Diego,

For all practical purpose, namespace are overrated :)

Threading is such a fundamental concept that it cannot be left at the edge.

Imagine if email didn't have any provision for In-Reply-To...

The "pragmatic" thing to do, in my case at least, is to look at my requirements (thread and attachments) and see what fit the bill best.

Considering that RSS 2.0 doesn't address these issues and that Atom offers a "good enough" solution based on its core elements, there is no contest in my mind about which way to go :)

Of course, YMMV.

"Additionally, the 0.2 draft spec of Atom makes no mention of threading or recursion."

Some "lateral" thinking for you:

http://www.imc.org/atom-syntax/mail-archive/msg01246.html

For reference, a "link" solution to threading is possible in RSS as well. In principle, I prefer a "link style" approach to threading, with all of the site's modified resources listed in the feed, with links and types indicating whether they are comments, entries, images, or media.

Hi Ken,

When you say "a "link" solution to threading is possible in RSS as well." which RSS are you refering to?

As far as RSS 2.0 goes, there is no provision for a 'rel' attribute.

Did I miss something?

Ken: As I understand it, the "funkiness" is defined as follows: "A feed is funky if it replaces core RSS elements with namespaces". Nothing more. I think that if RSS is taken as the basis and the core is not modified, there wouldn't be a problem, also considering Dave's statements on his weblog during the last couple of days. An Atom+RSS thing would be, as far as I understand it, compatible with RSS, and attributed as such. However, I can't speak for Berkman or Dave, maybe if he tunes in at some point he might be able to explain further (or correct me if I'm wrong).

Zoe: as far as I can see the threading solution you are pointing to is Joe's interpretation of how things should work. He clearly says "Note that the above examples of using the link tag aren't normative and that they are open to interpretation". Furthermore, it's not codified in the spec. Even more, Joe's statement directly contradicts the "consensus" shown in the example here: http://www.intertwingly.net/wiki/pie/CommentEntryExample

Therefore, this clearly shows that threading in Atom is yet to be fully discussed and properly defined. Why not discuss and define it as a namespace for RSS instead and build on what's already there?

Zoe: the context of the discussion appears to be "extend RSS 2.0 and create a new spec that is backwards compatible with RSS 2.0". In that context, a new spec can add a "some:link" element that would work. RSS 1.0's mod_link, for example would be more appropriate for RSS 2.0 than for RSS 1.0 (RDF does links inherently).

This is what I think *should* happen:

1. require all versions of Atom feed to be backward compatible.

2. adopt RSS 2.0 as Atom feed version 0.0

3. salvage good ideas from Atom 0.3 'spec' and package them into a few modules. They will also serve as examples of how modules should be defined.

4. publish Atom 1.0 feed format as Atom 0.0 plus some modules from step 3. Remaining modules are declared optional.

While Dave might not like it, I don't think there is a need to retain the name 'RSS" except to say 'Atom' feeds are based on RSS 2.0 format and are backward compatible with RSS 2.0.

The end result is that all the software will keep working and new software will work with the old (Atom 0.0) feeds as well as new feeds (Atom 1.0). As a developer, I can store and serve feed data with less headache.

Re: "While RSS 2.0 has some fuzy notion of "enclosures", Atom provide a clear and simple content element. Problem solved"

What's fuzzy about enclosures? The RSS 2.0 spec makes it clear that they're a means of attaching a file to an item in RSS.

Additionally, the source element provides the in-reply-to information you think RSS 2.0 is lacking. Perhaps Atom does it better -- I'm not familiar with the spec -- but it seems from your critique that you're not particularly familiar with RSS 2.0 either.

"this clearly shows that threading in Atom is yet to be fully discussed and properly defined"

Yes. Working on it as we speak. But it has the right core to handle threading properly once and for all.

"Why not discuss and define it as a namespace for RSS instead and build on what's already there?"

I already tried this... and... surprise... surprise... this went strictly nowhere.

Don, Diego: how do you solve the "HTML in title and description" once and for all? The only solution that is apparent to me is to define new elements that are more specific, but are redundant (or "replace") existing elements.

Hi Roger,

"but it seems from your critique that you're not particularly familiar with RSS 2.0 either."

Right... thanks for being constructive :)

enclosures... please refer to the RSS 2.0 mailing list. No point in repeating myself ad nauseam.

source... this only points from a child to a parent (?) feed. It need to point to a specific item also.

An item also needs to point to its children.

In both case, feel free to refer to the RSS 2.0 mailing list for additional informations.

Hi Roger,

"but it seems from your critique that you're not particularly familiar with RSS 2.0 either."

Right... thanks for being constructive :)

enclosures... please refer to the RSS 2.0 mailing list. No point in repeating myself ad nauseam.

source... this only points from a child to a parent (?) feed. It need to point to a specific item also.

An item also needs to point to its children.

In both case, feel free to refer to the RSS 2.0 mailing list for additional informations.

I'll say from the outset that I don't consider myself in either camp, as it were; I'm an external developer who wants a decent standard to code to, and these are my observations.

The questions that I keep seeing thrown around this discussion are:

1. What can Atom Feed do that RSS 2.0 can't?
2. Why don't Blogger and MT use RSS 2.0?
3. Now that RSS 2.0 is under a CC licence, why not just make a fork that fixes its problems for Atom?
4. Why is the Atom development model so slow and messy?
5. This is all about politics, isn't it?

1. What can Atom Feed do that RSS 2.0 can't?

As has been previously pointed out in various areas, the point of Atom Feed is not so much to provide new features as to provide a feed format with considerably fewer areas of doubt and uncertainty than RSS 2.0 has, while still providing carefully-defined but still open room for extensibility in the vein of other well-behaved XML formats.

However, since you ask, here's one particular feature that Atom's developers would like:
To be able to specify dates in the most popular and widely-used format within the XML world, namely Dublin Core format.

And therein the whole problem lies.

I don't really know why this is such a sticking point, since RSS has a date format already and it seems relatively unambiguous. On the other hand, anyone implementing a reasonably full-featured RSS consumer already has support for parsing dc:date, since RSS 1.0 uses it, and it's much more widely-used in the XML world, thus providing an easy compatibility route with existing XML-consuming code that then wants to consume RSS.

The wish to use dc:date unearthed the problems with RSS 2.0 that led to Atom.

According to the spec, RSS 2.0 lets you use dc:date instead of pubDate. Except, apparently, it doesn't let you do it. Or it does, but it's bad. In fact, I have yet to find a clear answer on whether using dc:date in an RSS 2.0 feed is valid or not. (This is one of those areas of doubt and uncertainty that I mentioned earlier)

2. Why don't Blogger and MT use RSS 2.0?

I have no idea about Blogger, but MT has supported RSS 2.0 from the word go, as far as I can tell. There's an RSS 2.0 feed template and it appears to validate just fine. However, the creator of RSS says that MT does not support RSS 2.0 properly. Eventually, after much handwaving and detective work (rather than, say, actually explaining from the start, which might have avoided some of the political problems that RSS and Atom are mired in), it transpired that this was due to its use of dc:date, despite this being valid according to the spec.

In short, the answer with regard to MT is one of the following:
a) MT supports RSS 2.0 in a valid manner and always has done.
b) MT does not support RSS 2.0 in a valid manner and therefore there is a problem with the existing specification.

3. Now that RSS 2.0 is under a CC licence, why not just make a fork that fixes its problems for Atom?

Because it'll break RSS 2.0 for everyone else. Putting a standard under a CC licence and thereby making it open for random rewriting does not fix a standard's problems, it just makes them worse by encouraging people to change the standard a billion different ways, thus making the life of developers like me utter hell.

One of the (highly-admirable) aims of RSS was overt simplicity, encouraging users to look at the format, understand it instantly and reproduce it accordingly, in a similar way to HTML. Unfortunately, as anyone who has to implement an HTML consumer will tell you, doing it in a way that can comfortably parse even 50% of the web's pages is damn hard work. RSS isn't anywhere near as complex a problem, but inviting liberal rewriting and ambiguous interpretation of a spec takes things in a dangerous direction.

Were Atom to fork RSS as encouraged, it would merely be exacerbating the problem. Plus, there are the problems that Ken has outlined above.

4. Why is the Atom development model so slow and messy?

Because that's what Internet standards development tends to look like. It's not for nothing that the IETF has become known as The Organisation For Building The Internet Agonisingly Slowly. And just because the spec is still 0.x doesn't necessarily indicate a massive problem, since RSS 0.91 was an active standard too.

However, Atom is going far slower than developers such as myself would like. If the spec doesn't reach initial recommendation level soon and Blogger still uses it then it may end up having the same forking problems as RSS now does. I don't take part in Atom development so I've no idea why it's going so slowly, nor why Diego's contributions were not used, and both of these disturb me.

5. This is all about politics, isn't it?

Certainly, there's far more ugly mud-throwing from both sides than is remotely necessary. This posting will probably be taken as mud-throwing too, though I certainly don't mean it to be, as I don't know any of the people involved personally, I'm sure they're all quite lovely and I have no wish to offend anyone.

So, I'd better go ahead and offend both sides at once from my middle ground:

I am an Internet code developer.
Right now, I refuse to use either Atom Feed or RSS 2.0.

I refuse to use Atom Feed because it's not fully specced and attempting to implement it might do more harm than good. Also, certain things I've read about the Atom standards process (such as Diego's post above) leave a bad taste in the mouth. Of course, Internet standards development, like democracy and sausage-making, is really not one of the things one should watch if one wants to keep one's lunch.

I refuse to use RSS 2.0 because I still have no idea what valid RSS 2.0 is ever since the whole dc:date fiasco, and that word which everyone knows but I refuse to use because it's utterly meaningless and makes me want to sling more mud. After being told by RSS's highest authority that the RSS 2.0 my MT install was producing was wrong, yet valid (according to every validator out there) and that authority refused to divulge what the actual problem was, I threw it away. I wouldn't use a compiler that just said "Your code is wrong" and didn't tell me why, and this is no different. I have no time for that. (Hell, I don't even have time for writing this, but I was always terrible at prioritisation, and the whole RSS vs Atom fight is as hard to look away from as a particularly gruesome car crash)

What both of the above have in common is that I'm impatient, which is one of the virtues of a programmer (according to Larry Wall). I don't want to wait for Atom Feed and I don't want to be left hanging around waiting to be told exactly what's wrong with my RSS feed.

So I use RSS 1.0, because it's utterly specified, unambiguous as far as I can see, it's not going anywhere and everything supports it.
Were Atom to just take RSS 1.0 and rename it Atom Feed, that would be just fine with me, and then I could get on with producing useful code instead of feeding flame wars.

-- Yoz

First, I sent an email to Evan Williams based on his post here, and included a link to Scott Rosenberg's article in Salon, suggesting we pursue this idea.

To Ken and Diego, I don't understand the issue. The 2.0 spec has to be somewhere, right? People didn't like that it was on a vendor site, so I moved it to a university. And that's not good enough? Why? I don't get it. Maybe I'm missing something.

To Zoe, smiley or not, the way people keep me from participating in these discussions is by saying nasty personal things about me. You do a lot of that on mail lists, discussion boards, everywhere. I see it for what it is, a way to control the discussion, and I'm going to participate anyway.

To Don, I would like it if people started with the RSS spec, evolved it into something that wasn't called RSS. Read the Roadmap. That's what it says.

To Rogers and Diego, thanks for considering what the spec says. In so much of the arguing people say things about the spec that are not consistent with what the spec says. It's not a long spec, and it's designed to be easy to read. To participate in these discussions without referring to the spec is not cool, it doesn't further understanding or communication.

Dammit dammit dammit - huge apologies. That massive post I just sent was originally meant for here, then I changed my mind when I saw how long it was and how far the conversation had progressed, and then somehow (mainly through unjudicious use of the STOP button) it ended up here anyway despite me now putting it on my blog where it belongs.

Profuse apologies to all, especially Diego. Please feel free to delete the previous post. Comments about it should be directed here:
http://cheerleader.yoz.com/archives/001639.html

5{ a lot of that on mail lists, discussion boards, everywhere."

Sorry about that. I will be the first one to admit that I don't always have the strength of character to handle your attics in a "proper" way.

But, let's move on :)

"Why can't we work out our differences? Why can't we work things out? Little people, why can't we all just get along?"

-- President Dale

Dave,

I think your stated position regarding extending the spec is clear, and that there would be no problem with that, and that's what I said. I didn't state it as a fact simply because I wanted to make clear that it was how I viewed things. However, given what you've said in the past, plus the last couple of days, plus this comment (including what you replied to Don), I think the situation is clear--thanks for the further clarification.

And, regarding referencing the spec, just in case I've added a link to it in the main text to make sure it's readily accessible within this context.

Plus:

*To everyone in general* again, please refrain from making personal comments. Things like "you have obviously not [read/done this or that/whatever]" aren't relevant to the point. If someone is expressing an opinion that I think is wrong, I respond to the opinion rather than attacking the person. Also, responding to attacks with more attacks is just as useless as the attack in the first place.

This last point in particular regarding a a comment by someone called "jt". To this person, please send me an email within the next hour and I will modify your comments to reflect your name. Otherwise I will delete your comments, since it's my comment policy (see link at the end of the entry) to delete anonymous comments, regardless of what they say (otherwise I have to be making judgment calls every five minutes). I'm making this allowance since the comment is already posted, anonymous comments posted after this one will be deleted without warning as the comments policy specify. Thanks all!

Yoz, isn't it obvious that it weakens a format if:

1. MT chooses to use something from an extension when the core already specifies a way to do it.

2. They ship RDF as the default format, not RSS 2.0?

Because of both these issues, it's impossible to say that MT supports RSS 2.0 in any meaningful way. Support is not only a technical term, it's also a term of friendship. If you support something you don't also undermine it.

Your argument rests on a technicality. Sure, their optional RSS 2.0 feed validates. It's valid. You're right about that. But it's not supportive.

RSS is weak. I say MT took advantage of that weakness to make it weaker. I say I don't like that. You think that's mud slinging. I say it's me expressing my opinion about something I'm an expert in. Kind of like Bruce Schneier expressing an opinion about security or Linus expresssing an opinion aobut Linux. .

Technically speaking, "Atom as RSS" becomes a new line of RSS development, is that what everyone proposing to use RSS is seeing? When Atom (as RSS, or not) is near complete, it will be submitted as a Internet Drafts ultimately seeking to be posted as an IETF Informational RFC. This will be the "official" Atom spec. Future Atom specs, as they are submitted also as RFCs, will "supersede" previous versions, as IETF RFCs are wont to do.

For sake of discussion, let's say Atom produces a "more tightly specified spec, with test cases and reference implementations to keep the specified portions tight." This will be "different" from RSS 2.0 in an as-yet-unknown way (maybe small, maybe big). If Atom *isn't* RSS (in name or in clear spec succession), what benefit does Atom have in being based on RSS?

Dave, sorry about the under-estimating your generousity.

Ken, I think the tag should be introduced in Atom 1.0 to supplement . works for 'linking' resources to an but will be useful for 'embedding' arbitrary MIME type content. Atom 1.0 should guide developers away from using HTML in and without preventing them outright because that will break backward compatibility.

Urgh. Here is the escaped version

Dave, sorry about the under-estimating your generousity.

Ken, I think the <content> tag should be introduced in Atom 1.0 to supplement <description>. <enclosure> works for 'linking' resources to an <item> but <content> will be useful for 'embedding' arbitrary MIME type content. Atom 1.0 should guide developers away from using HTML in <title> and <description> without preventing them outright because that will break backward compatibility.

Ken, to paraphrase President Kennedy:

*Ask not* what RSS can do for Atom but ask what Atom can do for the *users*.

There are lots of benefits Ken, many of them psychological.

For developers of content tools and aggregators it means supporting Atom is a much smaller job. If the features make their service to users better they will have a totally positive feeling about Atom. During the summer, when a few Atom feeds started appearing, I wrote a format driver for Radio for Atom. It was not fun because there were so many new things that were unspecified or underspecified.

The advantage for non-techies is familiarity. They do look at the feeds. It's a fact. So when they look at an Atom feed they'll say Oh it's just a flavor of RSS, and there will be nothing controversial.

And more generally, it'll be a *historic* example of developers working together to build something without tearing down something else. We can honestly, at that time, claim to be adults.

Don, in "Atom as RSS", yes, Atom 0.0 would be RSS 2.0. That means, functionally speaking, we're working on Atom 1.0, which is functionally "RSS 2.0 Next Generation". Some of the things in Atom are "more tightly specified" versions of elements in RSS 2.0. To be very clear, as a module they would be functionally redundant to or replace RSS 2.0 elements.

A lot of Atom is about exploring alternatives, writing them up as more than just a "back of the napkin" suggestion. Let's take this to the next level and write an Atom format spec as it would look based on RSS. How would you like to do that?

To Ken:

"extend RSS 2.0 and create a new spec that is backwards compatible with RSS 2.0"

RSS 2.1 :)

That would be great!

I personally only need two features to be added to RSS 2.0...

Something along these lines:

- add an xmlUrl attribute to the comments element to allow it to point to a RSS feed representing said comments.

- allow for multiple enclosures in an item.

That should cover it, alongside a clear example illustrating how to represent a thread in RSS 2.1.

Check the RSS 2.0 mailing list archive for additional details.

Ken, I'll think about it. At the very least, I'll help out in the 'realignment' process.

Dave, thank you for your clear explanation of your position with regards to MT and RSS, because I really wasn't sure.

However, a few things:

1. My MT install came producing both RSS 2.0 and 1.0 out of the box - they were both "default". (I don't know whether things have changed since then)

2. You say "Your argument rests on a technicality". That's correct, because we're talking about technical standards here. Hence, when you originally said that there was a problem with the MT feed, it appeared that the problem was technical, because there were no clues otherwise.

The word "support" can mean different things.
WordNet says:
1: the activity of providing for or maintaining by supplying with money or necessities
2: aiding the cause or policy or interests of

You're saying that MT is not going along with the second definition, and I understand that. I'm not accusing you of mud-slinging, since you've explained your position. However, as a developer, I care far more about the first definition. I don't have time to take part in policy movements and causes unless I have to. What I want, in the classic words of the IETF, is rough consensus and running code. If I'm implementing or using a new spec, I can't go through reading all the blog posts around it to find grey areas - the spec should be enough.

Would a solution (to the MT problem, at least) perhaps be to modify the existing RSS spec to specifically disallow the replacement of existing tags with tags from other namespaces?
(And a technical question based on that - how about if both pubDate and dc:date were used in a feed? Would that be okay?)

Just a small comment to Zoe re: calling it "RSS 2.1". I think that (as Dave has said more than once I think) calling something RSS when it's **evolving separately** from it is a bad idea. RSS is frozen, that's it, RSS is RSS is RSS. No "2.1" confusion. Atom can take RSS and build on it--Don's example of how it could be done sounds good to me. It's just a name issue and I think that this could have been avoided easily with the RDF-based 1.0 spec if a different name had been chosen.

Ken and Don: +1. I am pretty busy for the next couple of days but after that I volunteer to get working on it.

Yoz, what I would like Movable Type to do is to produce a dead-simple RSS 2.0 feed, and make it the default, so that we could get past this silly argument about which format is better. Note that I said "I would like" not "They must" or "I'll kill them if they don't" or whatever people think I'm saying when I express my opinion.

I would like the target for aggregator developers to be as small as possible so that independent sole-practitioner developers can compete. If there are things that RSS 2.0 doesn't do that we need to do, let's *work together* on a new format, derived from RSS 2.0, with as few changes as possible, that does what's needed. Since the format called RSS is frozen, let's not call this new format RSS.

Let's be ultra-conservative in the changes so as not to rock the boat. We've got a good thing going. Let's get growth back in the software business. I know Yoz, you don't have a stake in this, but I do, both as a technology investor and as a user. I remember what it was like when the software business prospered. We got lots of new toys all the time. I know we can get back there. But we need some rock-solid platforms to work with. RSS is the leading horse in this race. Let's strengthen it, not dilute it.

Re: Name

I don't mind names one way or the other. Call it whatever you want, except Atom :)

But to be quite frank, I'm a little bit confused about this entire thread to start with :/

As you said, "RSS is RSS is RSS". Fine. I don't mind.

Now... Atom comes along... doing its own little brainstorming about what a syndication infrastructure should be... fine.

But... out of the blue... somebody... somewhere... starts a new meme: what about retrofitting RSS in Atom?!?!

Yes, why not... this is a free country after all... but... why bother?

RSS and its supporting cast are fine as they are (re: the power of simplicity). And if they are not, well, they could be amended one way or another.

But what does this has to do with Atom? In my point of view: nothing whatsoever. Except that they both deal with syndication one way or another. So what? What's wrong with some competition?

Diego, your last comment regarding the RSS 1.0 name is off base. While stating your opinion on your blog is entirely up to you, unless you want to devolve this thread into that discussion, it's better not to lump that naming consideration in with any other or more recent naming consideration. Better to have just said, "No, use a different name." without the oversimplified generalization of the deeper issues that resulted in RSS 1.0.

Ken, you're absolutely right that I shouldn't have dragged past issues into this. That is my opinion but it's also true that I didn't participate in the discussion at the time. We should be looking forward, and not back. I apologize.

As long as we're talking about consolidation, there's another avenue that would simplify matters: The RSS-DEV Working Group should declare that RSS 1.0 has been superceded by two syndication formats: Atom and RSS 2.0.

It seems to me that there are many common motivations and goals between the creators of RSS 1.0 and Atom. Since RSS 1.0's last active development was in 2001, and the format's name continues to cause confusion for many adopters of RSS, it would be of benefit to the community if there were only two competing formats with different names: RSS 2.0 and Atom.

"RSS 1.0 has been superseded"

Hehe... :) Good one!

I'm sure this will go down well with the RDF crowd: you have been made obsolete by Rogers Cadenhead. Time to disband.

On the other hand, the same twisted logic could be applied to RSS 2.0 vs Atom:

"The RSS 2.0 Advisory Board should declare that RSS 2.0 has been superceded by a new syndication format: Atom."

Since RSS 2.0's last active development was in 2002...

Rogers, as we've been down that road many times before and there appears to be no need to discuss it again now, I'll just reiterate that I strongly disagree.

I was told a few months ago by an industry veteran that 'an API and a feed format should be complementary and designed to work with each other' and that you 'couldn't talk about one without the other'. Good advice, perhaps?

Atom has been designed to work in tandem. Former syndication formats carried the burden of not being designed from the ground up in this manner. This is the biggest benefit thus far, the ability to look to other sources for inspiration but at the end of the day have a well designed API and feed format designed specifically with personal content in mind.

At the end of the day the 0.1's and the 3.0's don't matter to the users of blogging services and software. They want easy to use tools that work well, let's not forget that in all the finger pointing.

Zoe: regarding your earlier comment that ended "what's wrong with competition?".

You say there that you are confused by the thread. I think that what we're saying is that it would be much simpler and less disruptive if, at this point, RSS was adopted as the Atom syndication format. Nothing more, nothing less. I know that my life as an aggregator developer would be simpler if that were the case.

Rogers: (just my opinion) I think this is an emotional issue enough without adding more, as I said in my reply to Ken, let's look forward and not back. In any case, the place to discuss that would be the RDF syndication forums where the stakeholders involved in that can comment themselves. Let's just keep it to RSS 2/Atom.

And Zoe, please I know that this is your style (from experience :) -- and I have no problem with it in general!) but in an emotional topic like this it's easy for someone else to reply with an "escalation" and then it goes downhill from there.

Jeez, I sound like a sanctimonious prick, repeating what everyone knows, but it's just that it would be great if we could have this conversation without degenerating into a shouting match. Thanks for understanding and bearing with me :-))

Jason, thanks for the comment. However, doesn't this contradict what Evan said at the beginning, that any syndication format would be fine? Which one is Blogger's "official position"? I have no issue with Blogger doing whatever it wants (I mean, I might have an opinion about it but it becomes a different proposition), but I think that at the moment it creates some confusion to not know.

Given your comment, what I understand that Blogger is committed to Atom as it is today and would not consider using a different syndication format than the one being discussed. Is this understanding correct?

btw, a general comment: I removed a few anonymous comments. Sorry, but as I said, whether they are for or against, I don't want to make judgment calls about it. Please add your full name and a valid email address (or weblog if you have a nickname).

I don't think we've been down this road before, Ken. Atom is shaking things up.

Are there any RSS-DEV folks with an active interest in continuing to release future versions of RSS 1.0 and competing with RSS 2.0 and Atom? Are there things RSS 1.0 can do that Atom can't?

It doesn't serve anyone's interests to have three competing syndication formats, two of which share the same name. If there's a genuine opportunity for consolidation, regardless of which formats are being branched together, now's an ideal time to pursue it.

Jason:

"an API and a feed format should be complementary and designed to work with each other"

I wholeheartedly agree with that statement :)

Even RSS 2.0 provides some of this complementarity: the MetaWeblog API somehow uses the RSS 2.0 format. Albeit "translated" in XML-RPC.

Translation which brings in own share of confusion, unfortunately...

Rogers, RSS 1.0 does RDF.

Ignoring that for a moment, let's talk about Zoe's point: if we're consolidating on an RSS derived format, then that means Atom would be the clear successor to RSS and there would be no "RSS 2.0 vs. Atom", is that your position? I don't believe it is, nor do I believe it is the position of several others.

If Atom's syndication format shares the same keep-it-simple and keep-it-readable philosophy as RSS 2.0, I could envision supporting it as a successor. But from what little I've gleaned from skimming the Atom wiki, it seems to be the SOAP to RSS 2.0's XML-RPC.

"SOAP to XML-RPC"

I have to confess that this was my initial impression also.

But then, out of curiosity, I took the time to take a closer look at the actual spec and API.

The outlook is much better :) My advise: skip the wiki noise and go study the spec draft itself.

For reference, there's an Atom proposal (SSFF) that takes the format virtually back to RSS 0.9 (less the RDFish parts, even) and puts all the metadata in the entry resource. One of the advantages to brainstorming on a clean slate.

Diego,

"I think that what we're saying is that it would be much simpler and less disruptive if, at this point, RSS was adopted as the Atom syndication format. "

Perhaps in theory. Or if such a decision was made much earlier on. But now it looks to me as this is way too late in the game to try to retrofit RSS 2.0 in Atom. Sorry. Time out :) The window of opportunity for consolidation is over. Atom is ahead of the game as far as its core format goes.

"I know that my life as an aggregator developer would be simpler if that were the case."

Perhaps. But as far as I can tell from my own experience, the situation is pretty much f*ck-up already no matter how you look at it. One format more, or one less is not going to improve anything in the short run.

I want to give Atom the benefit of the doubt :)

"If there are things that RSS 2.0 doesn't do that we need to do, let's *work together* on a new format, derived from RSS 2.0, with as few changes as possible, that does what's needed. Since the format called RSS is frozen, let's not call this new format RSS."

Hmm.

Dave, what you say in the roadmap is " Subsequent work should happen in modules, using namespaces, and in completely new syndication formats, with new names."

If what you actually meant was "and in new syndication formats based on RSS, with new names.", then that is what it should say.

Perhaps you should issue a clarification to the spec.

Diego,

"an emotional topic like this "

Hmmm... why would a random syndication format be an "emotional topic" in any way?

You don't hear much sobbing regarding the move from RFC822 to RFC2822, do you?

Very baffling.

Zoe,

"You don't hear much sobbing regarding the move from RFC822 to RFC2822, do you?"

By "emotional" I don't mean people sobbing. This whole topic of the evolution of syndication has created huge discussions over the years, mostly going nowhere, and leaving the "sides" involved angry at each other sometimes to the point of not talking to each other. That sounds like an emotional topic to me. I don't see my comment as "baffling" in any way.

Other "format wars" have created as much discussion, creating enemies and such. I remember Mark linking at some point to a discussion on the evolution of HTML in a W3C list that was similar in tone, effects and results. So it's not unique.

Anyway, I will almost certainly refrain from commenting further on this thread. Although I'd definitely still like to see public statements from Blogger and Six Apart on what exactly is their roadmap for Atom adoption and how will they deal with evolution issues in the format (as well as how will they expose this to users), I think we know pretty much where everyone stands today. As I said in the post, positions appear to be too entrenched to try to reach an understanding. I guess that we'll just have to wait and see how it plays out!

Diego,

Just take a look at this conversation: at the time of this posting, 55 comments and 4 trackback!

All this nicely package in a totally flat structure dumped at the bottom of your post.

No hierarchy. No way to reference a particular comment. Artificial segregation between "local" and "remote". Not even a feed in sight to follow this conversation in any meaningful way. Nothing.

Ground zero of "communication".

And all the syndication Taliban flaming each other about what? "Mine is bigger than yours!"

This is laughable.

Diego,

"baffling" was referring to people getting emotional.

This was not about your comment :)

Zoe,

As far as flaming, I mostly see people expressing diverging opinions and not agreeing, but not flaming.

As far as the hierarchy, etc, if you're saying that Movable Type as I have it configured doesn't have enough features or that I haven't properly set up feeds for comments, you're right. But this is the software I prefer for the moment, and I haven't had the time to set up additional feeds. Sorry about that, I'll take a look at additional packages or config options for MT that would make following discussions easier. I might even have time to install one at some point. :)

"Syndicating and posting are very, very different"

Right... I'm glad you didn't design POP and IMAP then ;)

Diego,

This is not a problem with MT.

But yes, you could try to spice up your blog with an add-on here and there.

And then what? The existing syndication formats simply don't support any form of threading.

And if there are some obscur "namespace" which do, this doesn't matter as there are no SUA* supporting them.

*Syndication User Agent ;)

"RSS-ified content is the opposite where perhaps 5% of the users publish and 100% read."

This is your bias . I don't have such limitation :)

Thinking about the RSS 1.0 issue more, I'm probably not giving enough weight to the significance of the reintroduction of RDF to the format. If it's the only RDF syndication format, I can understand that semantic webbers would not want it to be superceded by any non-RDF format.

This discussion has been closed. Thanks to all who participated.