I've asked Tim Bray to co-chair the IETF working group, and optimistically updated the draft charter on the wiki.
Take this in the spirit intended, which is just a suggestion/concern Sam, but shouldn't you consider opening this selection up, based on the fact that Atom is community driven? And also, would it perhaps not be better to have someone who is not affiliated with a major computer company as a co-chair? You're IBM, Tim's now Sun.
It's just that so many of these efforts end up being driven by HP, Sun, IBM, or Microsoft or other major vendor. Now, perhaps the people working for these companies in 'researcher mode' are the only ones paid to be part of this effort, but it seems as if there's only about ten major players in the world on these efforts, and they just circle around from group to group.
I may not be making my point well, and I imagine others working on Atom will agree with Tim being co-chair. It just seems a bit exclusive.
I don't like this. You and Tim have almost always been on the same side of every discussion. What's the point of having a co-chair if you're both on the same side?
(I'd also like there to be be people actually working at one end or the other of syndication involved in the process, but I'm naive like that. You choose who you like)
Shelley, I posted the draft IETF charter on the wiki, and announced it here. To date, I have received no feedback on the choice of chairs.
Sometimes the best way to attract feedback is to make a proposal.
"To date, I have received no feedback on the choice of chairs"
See above.
(Sorry to sound bitter, but you're running this process in an absolutely absurd manner - Announcing major new information at random presentations rather than to the group working with you on it, for instance)
I was going to write a parody, but I see Shelley's already done it for real. It'd go something like:
"Oh yeah, Sam, can you be any more obvious? Tim Bray goes to work for Sun one day, the next day you name him co-chair. All those denials of BigCo control are ringing pretty hollow now!"
Both directors have ample experience writing specs and discerning consensus, even when it contradicts their own opinions.
That they are both employed by the Usual Suspects is perhaps unfortunate, but it's hard to see how it would matter. If Atom turns out less friendly to small developers than RSS, it will fail.
Corporate affiliation is not a good reason to go with less experienced directors.
I don't understand what this BigCo hubbub is supposed to mean. Most web standards are written by the same small pool of professional standards people who float from company to company bearing little allegiance to them. Does it really make a difference who was signing the paycheck of whoever wrote the specs for HTTP, XML, WebDAV, RSS, etc?
The only thing of interest to me is that the news reports claim that Tim Bray will be involved in RSS and now Sam is trying to get him roped into Atom. Sounds to me like Sam is trying to force Sun's hand in choosing sides.
Ahhh, I love the smell of politics in the morning.
"I would suggest that you get one or more aggregator authors involved in the ietf specification process."
Us aggregator writers are annoyed that Atom exists in the first place. More parsers == more potential for bugs. Why would we support the effort to make us do more work and have more bugs with no benefits?
SemanticContext(*Formal)
Following on the comments of Mr. Tilkov and "Dan", I would suggest there's something to be said for merging the standards effort, and getting it back down to (roughly) two. (For an example, perhaps RSS .91?/2.0/3.0 and RDF 1.0.)
Furthermore, I'm somewhat incredulous that people would complain about what Mr. Ruby is doing, considering that Mr. Rod Smith (VP of "Emergent" Technology) and Mr. Jonathan Swartz (iirc, and don't know title) are discussing how to carve up the marketplace. And who makes money and who doesn't make money. Although I agree it would have been less conspicuous if this offer had been made prior to Mr. Bray's working at Sun and showing interest in RSS2.
"I don't understand what this BigCo hubbub is supposed to mean." There's a knee-jerk reaction by too many people. These people often being the same one's that ask, "How can we get this technology out to the MASSES", for some odd reason. I believe the bias against "BigCo" comes from people who actually believe the tripe of "radical decentralization", meaning they're not going to be satisfied unless THEY are the co-chair.
Sarcasm(*ON)
All we gotta do is just pretend EVERYBODY CAN BE THE CO-CHAIR...!
Sarcasm(*OFF)
I agree with:
"(I'd also like there to be be people actually working at one end or the other of syndication involved in the process, but I'm naive like that. You choose who you like)" as well as:
"I would suggest that you get one or more aggregator authors involved in the ... specification process. Experience with specs is useful; I suspect that experience dealing with specs in the real world would be more useful still....."
I would extend these further, and suggest that people that have 2 or 3 decades actual direct experience in Business Transformation would be useful, though hard to find. But they have experience in transforming manual processes to computer, which few of lesser experience have. (Of course, I'm not saying that only those who have decades of experience actually implementing systems can contribute good input, however.)
"Both directors have ample experience writing specs and discerning consensus, even when it contradicts their own opinions." This would illustrate the principle that good design can be negotiated better than it can be found by trial-and-error. There's room for both, but I don't have any question about which is more effective, which is the latter.
"Most web standards are written by the same small pool of professional standards people..."
And I think this is the largest part of the problem. It's not BigCo, but it's that people who are "tenured" with either a company or an academic institution will, invariably, negotiate a different design than those who have to actually implement the (sometimes Rube-Golberg-like...;-) theory on a timeline, in order to eat.
"Us aggregator writers are annoyed that Atom exists"
Speak for yourself. I aggregator writer am annoyed RSS continues to exist in non-deprecated form.
Graham,
That's interesting. Besides renaming some tags and adding the usual suspects when it comes to web standards to the author section of the spec what makes Atom better than RSS? If anything needs deprecating it's the entire broken model that pretends that date + title + content is the only significant information worth syndicating.
I've been working with RSS for about a year now and have followed the Atom discussions since they started. I haven't seen any major benefit of Atom, for every little nicety (adding a modified date) some cruft comes along with it (adding a created date) so at the end it's just another quirky, confused syndication format with too little in the core.
1. It requires dates. Having to rely on when an item is first seen by the software is really shoddy.
2. It has identifiers (remember one of the biggest issues to sorting out your synchronization format was how to identify items?)
3. It defines what one might find between the title and description tags. HTML, text, mixture of both?
4. It differentiates summaries and contents.
5. People are actually thinking about the issues re: standardizing content and syndicating, which was never done for RSS. Granted, not much has come from this yet, but at least the intention is there.
I came into the RSS scene quite late (May 2003), and had to put up with all sorts of confused specs, shocking flaws and being told Shrook wasn't displaying feeds "correctly" (when there's no such thing). When the Atom project came along, I assumed everyone else shared my frustrations and would be keen to sweep the whole RSS mess under the carpet and start again. Unfortunately some RSS backers took it personally, and some didn't see the benefits, which brings us to now. I still think one way or another RSS 0.9, 1.0 and 2.0 aren't long for this world - and Atom is currently the best bet.
SemanticStyle(*Informal)
1. It requires dates. Having to rely on when an item is first seen by the software is really shoddy.
If the authoring tool provides suitable dates, what does it matter. Iow, that sure appears to be a problem with the tools, rather than the spec. As far as I know, the RSS spec doesn't prevent these new dates either.
2. It has identifiers (remember one of the biggest issues to sorting out your synchronization format was how to identify items?)
I'll defer to others. I haven't seen what I think is a good design for items, so far.
3. It defines what one might find between the title and description tags. HTML, text, mixture of both?
That's an improvement, but not an innovation worth breaking all existing code for, in my opinion/observation (imo/o).
4. It differentiates summaries and contents.
People still seem confused about that, but it's a none-issue as I posted to RSS-User list. That's a PBKAC (problem between keyboard-and-chair), as it's a problem that people (authors and readers) do not see eye-to-eye on.
5. People are actually thinking about the issues re: standardizing content and syndicating, which was never done for RSS. Granted, not much has come from this yet, but at least the intention is there.
According to info (from John Patrick, iirc, but I believe anyway) IBM has somewhere around 20% of CMS market, so there's been at least some thought to this for a while.
But, more to the point, a lot of the thinking so far has been on how to kill off, or at least slow down, RSS acceptance. So the Atom effort has been a decidedly mixed-bag, to say the least imo/o.
RSS isn't long for the world?!? It has barely been started and shipped 500,000,000 Disney files, from what I hear tell. Glad you're anxious to have Disney, CNN, Yahoo, Nokia and all the other bit players they should scrap working code, Mr. Parks! But I wouldn't be, m'self.
I posted, 1/11/02 on TYR and Userland lists, iirc, to the effect that Radio/RSS could be lightweight replacement for browser, but even Scoble missed that one. (Wasn't on a blog, which are only things Robert finds suitable to read I guess...;-) I wuz optimistic, at the time.
What the heck is wrong with you folks? Tim did a good job with XML and I can trust him to do the same for Atom. If you are questioning his ability to remain objective, do that to his face instead of complaining about how the 'picture' looks. Since when did engineers become art critics?
Although I did more than my share of ragging on XML specs he had his hand on, I want him to co-chair Atom because I know nothing will prevent him from saying what must be said at the right time. Not even sunspots.
1. It requires dates. Having to rely on when an item is first seen by the software is really shoddy.
Like I said this is a nicety, in reality most feeds have dates.
This could easily be spec cleanup in a subsequent version of RSS.
2. It has identifiers (remember one of the biggest issues to sorting out your synchronization format was how to identify items?)
Again, a nicety. None of my users care about the fact that in the average RSS feed there is no global unique identifier for an item.
This is another thing that could be spec cleanup in a subsequent version of RSS or in an RSS profile.
3. It defines what one might find between the title and description tags. HTML, text, mixture of both?
It defines that they can be anything as long as it has a valid MIME type then there's the weird escaping vs. unescaped vs. embedded binary gunk. I also like the fasct that folks think that simply tagging some element's content as application/xhtml+xml means they're actually providing valid XHTML content (Yes, I'm refering to the boobs at Blogger). As far as I'm aware, the W3C never figured out how to spec how embedding XHTML in other markup formats was supposed to work and I haven't seen anyone in the Atom 'community' provide any rigorous definition either.
The spec is currently extremely ambiguous when it comes to providing content in a feed. If you haven't observed this then I guess you either haven't seriously read the spec nor have you written a fully featured implementation. Of course, I haven't done the latter either.
4. It differentiates summaries and contents.
This is useful. Although we already have this in RSS with description vs. content:encoded.
5. People are actually thinking about the issues re: standardizing content and syndicating, which was never done for RSS. Granted, not much has come from this yet, but at least the intention is there.
So they haven't made any progress or any significant headway but they should be commended because no one thought about the issues when RSS was being developed? I find that very insulting to the various folks who've been involved in the various RSS efforts from RSS 0.91 to 1.0 and 2.0.
<I>This could easily be spec cleanup in a subsequent version of RSS.</I>
I know it's technically fixible, but "the RSS spec is, for all practical purposes, frozen at version 2.0.1". Every initiative to fix RSS has gone nowhere. I think Atom is the nearest we're going to get.
<I>None of my users care about the fact that in the average RSS feed there is no global unique identifier for an item</I>
But they care that features like synchronization aren't commonplace, or don't work reliably? And that sometimes items show up twice when typos are corrected?
<I>we already have this in RSS with description vs. content:encoded</I>
Do we? It's totally informal. I don't think I could right a feature that relied on knowing whether I had summary or full content without Atom (obviously Atom won't be 100% reliable, but I'm sure it will be better).
I agree the Atom 0.3 spec is ambiguous and incomplete, and so do the people that wrote it.
Graham,
Thanks for explaining your perspective. The author of the RSS spec doesn't want to make some optional elements mandatory so the solution is to create an alternate protocol. I wonder how much progress the Internet and World Wide Web would have made if this was how decisions commonly made when replacing communication protocols and data formats.
Anyway, I've already gone over my monthly quota of posts about Atom/RSS/syndication technology. See you guys next month. :)
Tim Bray (on co-chair):
but I'm willing to give it a shot.
Well, at the very least we have the two of the best helmsmen steering the ship. That's a great start on the way to IETF. Thanks for accepting the offer.
After I wrote the comment, I realized it was a done deal -- Sam was co-chair, he asked Tim, we assume Tim would say yes, end of story.
Dare:
"I don't understand what this BigCo hubbub is supposed to mean. Most web standards are written by the same small pool of professional standards people who float from company to company bearing little allegiance to them. Does it really make a difference who was signing the paycheck of whoever wrote the specs for HTTP, XML, WebDAV, RSS, etc?"
I'm not sure if you're also indulging in parody with this statement, Dare, but yes I do believe it does make a difference. The whole point of Atom was it was not driven by a few strong people who dominate the process; that it was community driven.
However, in the end it is becoming somewhat business as usual.
There's no reason why this cannot continue to be a community driven process. In fact the IETF process actively encourages this by requiring people to reach a rough consensus. The products of the group will not be ratified by the IESG if it is overwhelmed by a few strong people without the support of other members. Anyone with an e-mail address and an informed opinion can be involved in an IETF working group. Having said that, it does often take a few strong people to drive through new standards so that the whole thing doesn't get mired in 'designed by committee' problems.
In fact, it often helps if the chairs of the group are not particularly active participants in the general discussion so that they can stand off somewhat and intervene with perspective as necessary for specific issues.
Shelley,
Interesting perspective. In the few years I've worked on software both Open Source and for large corporations I've never seen a successful development process that wasn't dominated by a few strong people. The ones that weren't ending up spinning their wheels since everyone had differing opinions and no one backed down or would listen to the others.
Based on watching the Atom process it has swung on both ends, anarchic then dominated by the familiar faces. At the end the usual suspects are bubbling to the top with some up and comers like Joe Gregorio also dominating the direction.
In the end it's just another syndication format. Slightly better than RSS in some regards, slighty worse in others. Whatever ends up happening RSS will be the Napster of online syndication, whether Atom can supersede it and become the FastTrack of online syndication will be seen. I suspect that Atom will end up being the Gnutella protocol of online syndication at best.
The reinventing syndication discussions aren't going to be over this year or next year. The fundamental concepts at the core of all the options are too short sighted and too limited to last that long. Of course, I might be wrong and people will just hack around them as Netscape hacked cookies into HTTP and Javascript into HTML.
I don't feel paranoia about both Sam and Tim working for Big Companies or being on the same side in many arguments. They both seem very skilled at cat herding, and appear willing to listen to the community, the majority, minority anyone. If anything, the Big Company angle is positive - they both appear to be attracting attention towards Atom from their companies, which has to be a good thing. I'm not sure it's accurate to talk of anyone 'dominating' either, I don't think that's part of their job description as chairs (and I believe they'll stick to that description), beyond generally trying to move things forward.
I think it's great that they've volunteered. Bravo!
btw, I certainly don't share Dare's slightly pessimistic viewpoint, to quote Alan Kay: "The best way to predict the future is to invent it."
I am not paranoid about both of them being co-chairs -- but I think there might have been some options that might have more easily opened the door with the RSS community. Perhaps I am mistaken and the RSS community will be delighted to see Sam and Tim as co-chairs of an effort that was supposed to unite these two disparate projects.
But yes, I would like to see new faces in these committees, and I'd like to see other strong but not as well known or as highly connected people involved in these efforts. Spread the wealth and exposure you might say. But if no one volunteered, then I can understand. Personally, I didn't even know this was going on until I saw this post, but I don't stay as involved as I used to. I imagine others did know and weren't interested. That's cool.
I think it's great that they've volunteered, especially if they don't get paid for this effort (i.e. not done as part of their jobs at IBM or Sun). It is not an easy job, keeping the project directed but still open.
Dare, I think where we're seeing this from two different directions is that I hoped this would be a unification process, but I think you're seeing two separate specs, two different directions. I'll have to admit, I probably did misread the IETF effort. If it is pure Atom, then it makes a lot more sense with Tim.
Did want to say that this is not a disparagement of Tim. I've seen Tim's efforts elsewhere with other spec efforts, and he is experienced, that's for sure. It was just me hoping to see some new faces, maybe some folks who have been on the more 'applied' side.
Shelley,
I haven't seen any indication that Atom is an attempt to unify the various flavors of RSS (the two main branches being the RDF branch and Dave Winer's family of specs). There has been no discussion about this on the mailing list nor has there been any wiki proposals on this to the best of my knowledge. Granted Atom has dropped of my radar but I still subscribe to the "Formerly Echo" feed.
Atom is yet another syndication format but this time it is backed by big name companies and has the web standards usual suspects on the authors column of the spec. I don't expect anything innovative to come out of this, just a formalizing of known best practices for the more popular scenarios in RSS.
What I'd like to see is inovations that make syndication more useful and palatable to the general populace but design by committee is never where you want to do that especially not with the web standards usual suspects.
Mark,
Sarcasm aside, Sam uses one of them. wfw:commentRss. Chris Sells called me, we talked and he blogged about what we came up with. Since then SharpReader has adopted as have the major .NET based blogging tools. Lots of my users love the fact that they can read the comments to a post directly from their aggregator.
Of course, if you don't use SharpReader or RSS Bandit you probably don't realize features like this are even possible.
Enjoy.
Damn, Dare, warn a girl next time when you're going to shatter a paradigm. My ears are still ringing ;-)
Sam, agree with you on standards having nothing to do with innovation. And when you repeat the info about the charter, does that mean we can indulge in juicy subversive wiki tactics?
(That sounds like a good conference presentation -- Juicy Subversive Wiki Tactics.)
This site already supports using the Atom API to post comments. Atom feeds can point to the appropriate URI to POST to using [link rel="service.post" type="application/atom+xml" href="..."] within an atom:entry. The person who invented the Comment API is now the primary author of the Atom API spec; he views his earlier Comment API as "one to learn from and throw away".
People who wish I were ignorant are often disappointed.
Shelley: let me put it this way, I don't expect to be talking to either Ted or Scott for at least a week. Even when I do, the they may require that a BOF be held before creating the working group. Or they may have their own ideas as to who would make suitable chairs or other input on the charter. Even if and when the working group is created, the charter can be always be modified.
Dare, Mark: I've added the appropriate link tags to my atom feed.
I blogged on the subject: [link]
But more help is needed. Two chairs is plenty, but two editors is, in my opinion, maybe not enough for two specs of this size. I'd be happy (and I assume Joe & Mnot would agree) to see some co-editorships. But only from people who can really put some cycles in. -Tim
This site already supports using the Atom API to post comments.
Cool!
Anyone want to volunteer to write an Atom API-enabled spambot?
Anyone want to volunteer to write an Atom API-enabled spambot?
This site has supported the Comment API for a long time, and there are no Comment API-based bots, unless you count Dare.
This site has supported the Comment API for a long time, and there are no Comment API-based bots, unless you count Dare.
Ah, but there is actually a hope that the Atom API might be adopted by more than 3 websites in the known universe.
Once there are more than a handful of blogs to spam with the Atom API, it becomes worth writing a 'bot to do so.
Perhaps a Reference Implementation in Python would be in order ...