Well, that worked, I guess.
Dave Winer says the W3C should talk with him about taking up RSS (emphasis in original):
If Atom turns them down, as it appears they will, the W3C can start with RSS, which has a much larger installed base, is better-known and has a five-year head-start. It’s the front-runner by a wide margin. Anyway, I’m still in Boston through the end of the month, which is right down the street from the W3C. They might want to try to talk with me about this. I have strong opinions, true, but I don’t bite.
That may be. But several times, I’ve read Dave state that he didn’t want to standardize RSS. A sample:
How about let’s try to put this back together so that RSS stays what it is, a simple syndication format, with a set of best practices that all parties adhere to, so that the format isn’t vulnerable to takeover by one or more BigCo’s. If you want to understand why I never took the spec to the W3C, there it is. It’s a consortium of BigCo’s with a director who is an RDF advocate, and until very recently an anemic patent policy. Such an organization cannot be trusted with RSS, imho.
I don’t think it’s necessary to explain how this is different from a group that has gone out in search of a standards body to advance their spec. If the RSS community were to come out united in saying they want to do that, that’d change things a bit, but wouldn’t necessarily derail our talks with the Atom community, who did that months ago.
Sam Ruby is a maybe.
Speaking for myself, my concern remains about openness, not time to market. Realistically the best that either the IETF or the W3C could offer is a chance for a completed standard in the first half of 2005, and neither will provide a guarantee that the standard will be complete in the second half of 2005.
I very much appreciate the doors being flung wide open, but what concerns me is small details. Details like the W3C permits, enables, and facilitates decision making in face to face meeting and teleconferences. By contrast, the IETF requires all decisions to be made on the mailing list.
First, we can’t promise a finished date for Atom because it’s not done yet. In order for us to estimate how long it would take to become a Recommendation, we first have to see a spec that’s close to complete (we call that a Last Call Working Draft). That is, the scope needs to stop expanding, and implementations have to start springing up to give some idea of the spec’s feasibility. It would be insane to assume that any group anywhere is going to plow through a spec this big without hitting a roadblock somewhere. In any case, the timing of a spec is 90% on the participants meeting their deliverables and coming to consensus. If they can’t do that, it’s not worth advancing, at either IETF or W3C.
Second, as was explained at the meeting, the process for things like attendance and decision-making can be set in the charter. If you don’t want to hold face-to-face meetings, or require decisions at them, fine. Likewise, if you want to do work on a Wiki, or on IRC, that’s cool too. (My understanding was that all official work in IETF must be done on the mailing list.)
Isolani likes most of it:
What is evident in Matt’s posting is that there is a passion about Atom inside the W3C. This passion is centered around the technical benefits offered by the Atom package. It is interesting to note that the W3C people who’ve come together to make this approach to the Atom community are from separate Working Groups. Each of them have independantly seen a benefit of working with Atom.
…but has a problem with company membership and how it affects voting. Specifically, he cites Mark Pilgrim and Sam, who both work for IBM, and how W3C rules say they would only amount to one vote. Now, here’s the thing we brought up in the meeting, and it wasn’t really recorded well: voting is a last resort. We work on formal consensus when that’s even a remote possibility.
It’s only after a complete breakdown in consensus that voting matters (emphasis in original):
A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, and that a vote is necessary to break a deadlock.
Were Sam and Mark to disagree, and neither one was willing to stand aside to let the group continue, how many votes IBM has is not the biggest problem the group has to deal with. This is true wherever Atom goes. W3C process is designed to keep one member company from steamrolling a group, which is where we get this rule. This is a feature, not a bug. (W3C Team – that is, employees like me – are treated like any member company in this respect.)
Wayne Burkett likes it:
I’ll let those familiar with each organization discuss the internal differences between the two groups. But while everyone close to the format contemplates completion schedules and decision-making guidelines – important matters, to be sure – I’m wondering which body will accelerate adoption of the format. To the average developer the W3C means Web standards. XHTML, CSS, and even XML, of which Atom is a vocabulary, are each W3C standards. The obvious consequence of hosting multiple successful, pervasive formats is that the W3C has become the Web’s de facto standards body (second only to the WaSP in a Google search for “web standards“).
Most developers are familiar with both the style and format of W3C documentation and with the validators that support it. Content producers, especially the newcomers who are summarily directed to a W3C validator the first time they ask for help with CSS, will be more likely to find and support Atom if it’s in turn supported by the same group that brought them every other standard with which they’re familiar.
Dennis Hamilton tastes good with syrup and butter:
I favor the IETF process, having seen it at work. I also fancy the way the W3C works to make some sort of coherent organism out of all the different pieces (and infection models) that have arisen around the World-Wide Web. It is interesting to me that the Atomists fear high-jacking in the W3C. It does seem easier to avoid that in the IETF process, except someone can come up with a competing solution there without much difficulty (using Informational RFC specifications, for example). You pay your money and take your chances. W3C specifications are easier to handle – they are Hypertext documents, of course, and they are on the web. For some, that’s a sexier result. Waffle, waffle, waffle.
So, where do we go from here? I think that more people approve of W3C involvement now than did last week, if only by one. The next step for us will be to bring the case, now approaching well-formedness, to the atom-syntax list, and see what happens.
