May: We at W3C like Atom. In fact, we like it so much that
we want to work on it. We like it so much that we're offering a
staff member to play the role of process sherpa. We're throwing the
doors wide open to anyone who wants to contribute. And in the
process, we're ensuring there's really no value in a company
joining the W3C to work on it. We're doing it because we get it,
and we care about it, and we want to help it succeed when it's made
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.
From my perspective, the IETF has extensive experience with
identifying and preventing behavior that is inadvertently
The one thing that I felt that was not adequately explored in
the meeting was the possibility that there might be a difference
from a legal perspective between these two organizations.
Unfortunately, I am not qualified to assess any such
P.S. I have a hard time taking seriously statements by
people that they get it when they don't even provide a
I think it is great that, despite its youth, Atom is so highly regarded in the web community. Much of that must be attributed to the way the collaborative process was set up in the first place, Sam. The boy done good!
I am glad that I am not making the decision, for both organizations bring great benefits to the table, and I would be hard-pressed to choose between them. I think, perhaps, I would probably favor the W3C approach. The process of turning it into a W3C Recommendation may be a little more arduous, but I believe the post-Recommendation benefits are greater.
Simon: "Atom is so highly regarded in the web community. Much of that must be attributed to the way the collaborative process was set up in the first place, Sam. The boy done good!"
Absolutely right. There is a fantastic community around Atom, and that is where the value comes from. The difficult step is taking that community bringing it into a W3C Working Group without damaging that community. It will take a lot of flexibility from the W3C to do this - and I don't know whether it can be done smoothly. People create specifications, not companies.
I'd like to clarify the 'open door' aspect a bit to help ensure we're collectively on the same page. Working Group membership at W3C is not an open door; you must present credentials and have those reviewed by both the chair and the Team contact. Then you can come on in. These processes are in place to help assure accountability, productivity and ensure Royalty Free licensing. There are hurdles. But these hurdles are relatively small for the accrued benefits.
From processing more of what I heard at the F2F, I think a proposal that included a Interest Group for supporting open, community participation and a publicly readable Working Group to help get things might be best. This combination provides a proven recipe that enables the 'open door' you mention but with a process that facilitates documenting consensus and producing timely deliverables.
This is a different model that the IETF and one the ATOM community would have to decide if it fits the groups best interest in moving forward.
Regarding your point about '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.'
I'd qualify this as well in the following. W3C permits, enables, and provides useful tools and infrastructure to facilitate decision making in face to face meeting, teleconferences and email. Expectations of how this should happen are stipulated in a Working Group charter (which I would suggest be public and citable). Again let me emphasis, stipulating these issues up front in the (IETF or W3C) charter is an important part in letting people know what they're getting themselves into :)
And finally on a personal note, I very much enjoyed the Atom Community F2F meeting and putting email addresses, names and faces together. Thanks Sam and Tim for pulling this together and moving us forward on several fronts.
My view, as someone who knows nothing about the internal workings of either organization, is that the W3C has the potential to accelerate adoption. Thousands of developers are already familiar with their specs and validators. Won't the same people who are summarily directed to the W3C each time they have a simple XHTML validation error be more likely to support Atom if it's in turn supported by the same standards body that supports every other standard they've ever heard of?
Is it accepted as a given that the final choice of a standards body won't affect adoption rates?
I tend to agree with you. My personal opinion would be to avoid the W3C based on past history for at least two reasons.
The first which you've accurately pointed out is that the W3C is by definition exclusionary; WG members generally must be from member companies although invited experts may participate with limited rights, decisions made in face to face meetings and teleconferences.
The second is that the W3C has proven track record of being unable to deliver a spec within two years. SOAP 1.2 took 3 years, XInclude is going on 4 years, XQuery + XPath 2.0 + XSLT 2.0 are all taking 5 years, the RDF specs have taken a similar amount of time since RDF 1.0, and so on.
DISCLAIMER: This is my personal opinion and does not reflect the opinions of employer with regards to working with the W3C.
Greg: We already are working on it. We're not going to take our ball and go home if Atom doesn't play by their rules, if that's what you're implying. The principal difference is that if Atom is at the W3C, contributing to Atom, and moving it forward to Recommendation, becomes our day job.
Kind of following up on Wayne's comments, but I think that it's not really understood by those within the cloister how much more prestigious the W3C is than the other one ... what was the name? ;-) The fact that Tim and some of the others involved are so experienced with the W3C is perhaps in this case a bug, not a feature, a forest-for-the-trees situation.
Syndication is a user-facing technology, not some behind the scenes thing like TCP/IP. Being a W3C standard is really important.
There's an order of magnitude or two difference there in brand recognition. Playing hard to get is great, in order to extract as many concessions as possible in the charter, but in the end, go with the W3C, for gods sake.
As I understand it, there aren't any openness issues that can't be addressed up front with the W3C. It won't be a typical group, but I don't think it would be wherever it goes...
I wouldn't like it if decisions were only made f2f, given that few of the developers are in reach of the corner of the US in which Atom meetings have scheduled to date. But decisions can be made via email - ok, we'll go with that then.
I don't think time to Recommendation is a major issue - the key factors there will be how well the group proceeds, something that should improve once formal procedures are in place.
Regarding brand recognition, imagine in two years time, what would be better for Atom: yet another RFC tucked away in relative obscurity, or a nice shiny pedestal alongside the XML spec?
Um. This is about a standardization effort, not a popularity contest. Developers will locate the standard wherever it is. It doesn't require "advertising" or "promotion" or any such nonsense. That isn't a useful "benefit".
Greg, it's absolutely a popularity contest. The standard Dave Winer counterattack to any Atom technical benefit is that RSS has inertia and is used by more of the big players. The standard outsider objection to Atom is that RSS is already good enough and is in use by all the big players.
People who don't know any better will choose by default the more popular of the two standards. Peter's comment that there's an "order of magnitude or two difference there in brand recognition" is just as important a consideration as any scheduling differences.
Wayne what you say is correct, that's why I suggested that the Google/Atom folk look at building on RSS's strength instead of trying to replace it, and then why I suggested that the W3C do the same.
The RSS 2.0 roadmap is flexible enough to allow the format to be completely redesigned if necessary, contrary to the hype we've heard. It just says the name of the new format should be different, which is hardly an onerous requirement, because Atom already has a different name.
Dave, can I ask what caused the about face with you wanting the W3C to pick up RSS versus these comments from May 14th?
"The W3C has been the roachtrap of standards. Ideas go in and don't come out. I turned over one of my creations to the W3C, and it died there, a long painful death, where it turned into a political football for dozens of tech companies. It might be better today because the tech world has shrunk, but hell, we don't need the tech companies, or the W3C. The former are bad actors, the latter is their consortium."
1. What I said is true. The W3C has a mixed record for delivery of formats and protocols that are useful and are widely deployed. The best work the W3C has done is XML 1.0. Very good. Everything built on that, well, judge for yourself. Not much deployment, for good reason. The formats are way too complex, and delivered long after it would have made a difference. An excellent example is SVG, something that truly had applicaitons, and if an existing model had been adapted (like Quicktime or Windows' GDI) could have been delivered in time to make a difference. I wanted Quicktime. Then there was SOAP, again, handed over the W3C in deployable form. Had they simply comitted to compatibility going forward, deployment would have been great, but now SOAP languishes, nearly irrelevant, and once held such great promise. I cared about both SVG and SOAP, because they were integral to my plans, one as the connector between tools and websites, and the other as a way of substantially upgrading the user experience.
2. Now people can learn from their mistakes. No reason not to. Once a roachtrap (I actually meant to say roach-hotel) not always a roachtrap. Having seen how it played out in the past, why would the W3C have to necessarily repeat the sam mistake in the future?
3. I'm generally a forgiving person, but I like to go into things with my eyes open. Honestly I think the W3C jumped toward Atom because they maybe unconsciously assumed I'd roll over in this case as I did with SOAP. Won't happen, I'm afraid, because with SOAP we had an excellent backup (XML-RPC) but this time RSS is the whole show. They'll learn that, and unless they repealed the law of gravity, so will Pilgrim and his colleagues. Stay tuned for the next chapter. ;->
4. And about the BigCo's damned right we don't need them. They're trying to hire their way into this market, and really throw their weight around (while they surely file patents, haven't heard any disclaimers, have you), but although they make a lot of noise, their agents didn't actually create any of this stuff. Sun is a shadow of its former self, and no one takes IBM seriously. Google will eventually back off the Atom-only regime, it'll be too expensive for them, maybe it'll be too late for Google when it happens, but I honestly don't care.
Thanks for asking. I wonder if Sam will let this stay.
This is what I said on Scoble's blog back on May 13th:
"This has nothing to do with Dave Winer. We (W3C) don't hate RSS. Never did. In fact, we use it. But in this case, we have a group that's looking to make a standard, and they're working in an area where we actually do have a lot of expertise. It's a good fit, and we're trying to show that to the Atom community."
As an invited expert for the W3C I might be considered biased, however I really believe that the reason standards take longer than they might is because a whole lot of work that people don't really see goes on behind the scenes. Often as things are discussed issues are discovered which have implications for a standard (as opposed to a company/product specific API). These have to be research and dealt with to the satisfaction of some very capable knowledgeable people before that standard can be finalised.
Although I cannot speak for W3C, I personally believe that a lot of the excellent work that has come from the working groups has been ignored as much for market position as anything. The browser wars were great for browser manufacturers, they weren't great for developers or users. If we really need to fall into all sorts of petty bickering every time something is being standardised then the progress is going to be slow and arduous. It is your god given right not to use a particular standard, but I just don't see the need to attack a perfectly a adequate process which is there to ensure quality.
And just in case anyone is interested, I manage to get to telephone meetings with my own money, with VoIP and other such telephony the cost is now negligible, it's not that we don't use mailing list or IRC, it's just that we use audio to it's best advantage to cut to the heart of discussion and find good resolutions among a large group of people.
Dave, I still don't understand how your suggestion of the W3C (or whoever) taking on RSS 2.0 is really any different from them taking on Atom as it stands. The name must be different, ok, it is. "Everything else can be redesigned as necessary" - it was realised early on that direct backwards-compatibility wasn't an option, especially in the critical case of the content handling. Atom is building on RSS 2.0's strengths, and hopefully those of RSS 1.0 as well.
How would you have things different than they are right now?
Matt, okay I get that it, whatever it is, doesn't have anything to do with me or RSS.
So what does it have to do with?
Who are you trying to work on behalf of?
Isn't the W3C a consortium?
Do you want to help developers?
Users? Publishers? All of the above?
Do you doubt that I have any insight into the issues of syndication techology and weblog APIs?
I find your position very curious -- but also not that uncommon. People are sometimes very picky about who they're willing to work with and learn from. But that's usually a losing strategy. You might prevail over the IETF, but what difference does that make? What is the goal of the W3C?
Anyway, the offer to meet is still open. I'll be at MIT later today, I could swing by.
It'll be hard to meet with us at MIT. I'm based out of Seattle, Eric is in Columbus, Karl is in Montreal, DanBri is in Bristol, and so on. :)
I won't dispute that you have expertise in syndication formats. That's not the issue. The issue is that the Atom community has decided that working within a standards body is the way to go, and the RSS 2 community has decided to roll their own. Clearly, you disagree with our view that there is value to Atom in working in a consortium like W3C, or submitting a proposed spec to a body like IETF. Which is fine.
I have to say the most exciting part for me is that Atom has the API as part of the package, and Atom is spoken end to end, unlike the MetaWeblog/MT/Blogger APIs. Irrespective of the format war, that's a pretty attractive feature in itself, and something that doesn't come with RSS 2.0.
The goal of the W3C, since you asked, is to lead the Web to its full potential. That includes having standards that work together, localize well, are implemented completely and interoperably, and are accessible, among other things. You think RSS 2.0 is good enough, and that's fine too, but the consensus in the Atom community is that it's not, and they want to build a format and protocol that better meets their needs, and create a recognized standard out of it. That's where we think we can help, both during and after the process.
"It'll be hard to meet with us at MIT. I'm based out of Seattle, Eric is in Columbus, Karl is in Montreal, DanBri is in Bristol, and so on. :)"
And don't you guys meet? So the impediment to meeting is obviously something else.
I think it's pretty obvious that the rest of your post reflects that something else.
"I have to say the most exciting part for me is that Atom has the API as part of the package, and Atom is spoken end to end, unlike the MetaWeblog/MT/Blogger APIs."
That might be interesting, if the primary functionality of RSS2 or Atom or any such is limited to blogging.
That might also appeal to people who have little understanding, and felt the same way about RDF/RSS1. But I believe you will eventually come to the understanding that:
a) It is not necessary for a format to be the one and ONLY POSSIBLE FORMAT IN EXISTENCE, in order to be useful.
b) People who think they can engineer utility and negotiate solid systems-design can develop somewhat useful formats, but there will be much better ways overlooked in the process.
c) The RDF-folks at the W3C and also the folks at the IETF are a little late in recognizing the value in RSS2, and there's a reason for that. Which I've just given above.
"The goal of the W3C, since you asked, is to lead the Web to its full potential. That includes having standards that work together, localize well, are implemented completely and interoperably, and are accessible, among other things."
Well, Mr. May, I think everybody is in favor of "motherhood and apple pie".
Let's elevate this discussion and cut to the quick, and take one-a these infamous votes: By asking the question in the negative. Anybody NOT in favor of this, please put your +1 below. TIA.
Let's assume that'll be a short list, and move on.
You've shown, Mr. May, exactly what I've said previously (although it could-a been in one-a the many deleted comments). Both the W3C and IETF are so far removed from both developers and users, that they have themselves relegated their proposed solutions to real-world problems to a bunch of theoretical bunk and fancy talk.
And I think it's pretty safe to say that any group that consists of 100% Young Turk Males is not at ALL representative. And they'll come to not-representative conclusions, and bogus ones like you've given above, no matter how fancy the talk to buttress the supposed-arguments.
Danny, the reason that this whole issue appears to be of great significance is that these specs are done by bloggers. You think it's a coicidence?!? That 100% of the spec-writers are bloggers, and blogging is the center-of-the-universe of the RSS2/Atom(/RDF) specs.
Well, blogging is only the center-piece in the mind's eye of bloggers.
..I think Dave is (in my view, correctly interpreting and) taking the "hint". One-a us is misreading Matt May's reply, and I think it's you because the issue was closed by Matt May and others of the same opinion. There are some in the W3C that have an alternative view, I gather, but they are few.
Also, who is this "Most of the RSS 2.0 community polled"...?? I hope it's not the scant and circumspect commenters on the link Dave provided?
Or is this one-a those infamous "votes" done via private email and such??
And don't you guys meet? So the impediment to meeting is obviously something else.
Dave mentioned a face-to-face meeting. What I said was that it will be hard for Dave to meet us at MIT, because none of us live there. Not that it will be hard for Dave to meet those of us who are based out of MIT. Which is to say, you're the one who's misreading.
That might be interesting, if the primary functionality of RSS2 or Atom or any such is limited to blogging.
No, not really. In fact, that's exactly the opposite of what I'm thinking: RSS or Atom only gets really interesting when it stops being just about blogging and bloggers. Like a posting model that works with generic content management systems. Or a polling model that makes sense with stock quotes or sports scores. Or user agents that index or cross-reference content over the Atom API. We wouldn't be so interested if it were just, and could only be, about blogs. (This reminds me of Brain Candy: "This is a drug... for the world... to give worms to ex-girlfriends. You just don't get it here!")
Well, Mr. May, I think everybody is in favor of "motherhood and apple pie". (re i18n, accessibility, QA)
Well, then, better to go to a group that provides the resources to (help) accomplish things like i18n, accessibility and test suites. That's what we're saying.
"Dave mentioned a face-to-face meeting." I can assure you that you can have a face-to-face meeting over the phone. If that doesn't suffice, I would point out that IBM published the figures that in the month of June, 2001 (iirc,) IBM saved $6 MILLION by using other technologies to accomplish these very things. (I believe that was in an iChat of July, 2001, but can't recall exactly.)
I would think you'd have access to similar, by now.
"No, not really. In fact, that's exactly the opposite of what I'm thinking: RSS or Atom only gets really interesting when it stops being just about blogging and bloggers.
Well, I'm glad there's at least two of us, then. However, human nature being what it is presumed to be, exactly when is this gonna happen? I mean, anybody can say it's not just about blogging, but then they also say that the advantage of Atom is it's integration with a blogging interface.
That would be a negative, rather than a positive, right?
Like a posting model that works with generic content management systems."
I'm sorry, but don't you need generic CMSs for this to be a benefit??
And please don't tell me that "All ya need is the plumbing, and these things'll be coming together! They'll be a-poppin' up like mushrooms, once we get this specific plumbing in place!!"
"Field of Dreams" was a Hollywood production, iow, which hurts a lotta people's feeling when I point that out...)-;
"Or a polling model that makes sense with stock quotes or sports scores.
Well, RSS2 is currently doing these, afaik.
I keep hearing about this pseudo-problem, almost exclusively from RDFers. This is a red-herring... The polling isn't gonna be a problem on a Net that is currently sending megabytes of A/V in real-time, spanning billions of people.
"Or user agents that index or cross-reference content over the Atom API."
I'm sorry, but you're finally getting into my actual domain of expertise. Indexing and cross-referencing are features that Atom gets in the way of, frankly.
"Well, then, better to go to a group that provides the resources to (help) accomplish things like i18n, accessibility and test suites. That's what we're saying."
This was a done deal in the late-70's or early 80's. The OS/5 ("i5/OS", in IBM-marketing-parlance) has always been strongest in EMEA markets (probably because those don't have the cash to blow that some American companies appear to have).
I, personally, know 3 people locally that made some pretty good bucks, in the late 80's and early 90's, doing internationalization/conversions of ERP and like apps. Simple to do.
So if you are looking for solutions, then a OS and/or DB that allows CCSID to be specified for each field (afaik, I have not actually done), and I believe that applies to Binary and Character LOBs as well..
..Well, I figure Oracle and SQL Server and such can do that already, but maybe not. (And if the OS and/or DB takes care of these pseudo-complexities, the display apparatus has little work to do, again afaik.)
The reference sounds interesting, but I'm not familiar. But whenever I see the phrase (and this comes mainly from bloggers, I've noticed) that someone or some-other-one "doesn't get it", I'm skeptical to begin with.
(Yeah, I know that may be how I, myself, come across at times. That's not how I am, even tho I may come across that way, however.)
Thanks for reply Matt, and to Sam Ruby for the bandwidth, technology, and all.. (and patience...;-).
Uhhhh... When I "said", "So if you are looking for solutions, then a OS and/or DB that allows CCSID to be specified for each field (afaik, I have not actually done), and I believe that applies to Binary and Character LOBs as well.."
I know, for a fact, that applies to Stream objects. But am not positive on whether that applies to BLOB and CLOB fields in the DB.
There is a whole unnecessary extra layer in the MetaWeblog API, with elements completely unrelated to the format. They are a complication Atom didn't copy, thankfully.
Actually, Atom (not to mention Atom over SOAP) does copy the complication of envelope fluff. The Atom envelope is superfluous in the most common (well, what I expect to be the most common :-) use case compared to POSTing the content directly.
As for packaging images with a markup document for POSTing in single go, I much prefer the OpenOffice.org approach of using a PKZIP container over the MIME and Base64-based alternatives.
Henri, while you're right about Atom using an envelope, your argument's a strawman. It may be superfluous in one use case but it isn't in others. My personal ideal aggregator would be using a back-end store, allow clever search/query and by default minimum chrome. That's a long way from current browsers. Yes, you could put the metadata inside the content. But in most cases it makes life a lot easier the other way around.
Yes, you can use a browser as the UI for a server-side system, but unless you've got very good connectivity, this isn't an option.
That's leaving aside the difference between messages and procedure calls.
I guess my reply to Matt is also to you, then...;-)
"I was merely trying to establish who controlled RSS 2.0 right now."
Good luck on that one, pal...! (Iow, you, me, and a host of others have tried similar, but seems ta-be a moving target, huh...;-)
However, I would like to point out that Dave has shown the better methodology. "Not too loose, not too tight" is a difficult balance and, imo/o, Dave errs on the side of too loose, too often (spec-wise).
However, that'd be the side to err on (I'd think obviously, given the results).
I'd be interested in hearing the pros and cons of different kinds-a envelopes. Seems like a solid RSS2 spec would obviate the need, but dunno for sure.
"Yes, you could put the metadata inside the content. But in most cases it makes life a lot easier the other way around."
This, I gotta admit, I don't get... I mean, it's easier to data-enter the metadata inside, but sure seems easier to store outside the content, a la some-a Ted Nelson's ideas. And SO easy to go back-and-forth, afaik, I dunno why this isn't done. (Or am I so lame not to have seen it being done this way?)
"Yes, you can use a browser as the UI for a server-side system, but unless you've got very good connectivity, this isn't an option."
Well, I've seen a lotta discussion that the Intranet is going to become same-as the Internet. Which is funny, because in the circles I used-ta travel in (the OS/5 community), there is no difference, whatsoever. Almost EVERY BIT of Intranet activity IS through the Internet Protocols. There's almost 0% NOT going through the IP, in every intranet I've been involved in, or heard of, over the past.. oh.. 8 or 10 years.
So I don't get it again, mebbe? ;-D
"That's leaving aside the difference between messages and procedure calls."
There's a difference? ;-D
Iow, I'm fortunate to have access to easy methods of either, but better yet the OS determines whether it can do the physical I/O synch or async. (And it measures how much of each it does to the drives, but few pay that a whole lotta attention, frankly.)
I do know that there's a place for both. And that's in either a distributed or non-distributed view of the architecture, at least afaik.
1. The people who complain about the spec didn't offer help when it was being created and edited. Only a very few people helped, and they just contributed feature ideas, not "camera ready text" as it's being called these days.
2. The spec was catching up with practice. That's why RSS is such a growth machine -- the users lead.
3. The users control RSS, always have. It's a nice dream to think anyone or group can control something so diverse. If you want to understand, ask if Tim Berners-Lee controls HTML. If so, why aren't we all using XHTML, and why are people still using tables for layout?
Dave, a lot of people were prepared to help with the 0.94/2.0 spec. You were even presented with simple options that could have united both RSS 1.0 and the 0.9x thread. It was also suggested at the time that you should allow more than a couple of days for comments. If you had, then you might have avoided the silent data loss 'storm'.
The end users of RSS don't care about the format, they just want what it enables.
"Dave, a lot of people were prepared to help with the 0.94/2.0 spec."
I observed the 2.0 spec being created, (I think made a single comment, at the time,) and have read a lotta the history of prior. I recall you saying, over at Andrew's iirc (approx), that "Dave alienated a LOTta people when the 2.0 discussion was going on."
I observed there was a LOTTA alienation going on, in BOTH directions.
Do end users really care about the details of format?
I think everybody agrees they don't, like you said above. And neither developers nor users know which features are gonna be considered the must-haves, since the environment is still very nascent and there's a lotta innovation going on, at least up until now.
Mixing up the notion of specifications and the implementations of those specifications does nothing to help understanding.
On the contrary. Developing specs without sufficient regard to implementations is the current state of affairs, and has been so for far too long.
These latest threads, like "all others" before them, reminds me of Mark Pilgrim's article (which I appreciated at least the tone of the writing, although it was more-a-the-same-ole-same-o as usual).
Mark wrote,"If you haven't torn all of your hair out by now, here are some additional links that are required reading for anyone silly enough to want to write a syndication consumer:" and he provided links.
This is to mean that one has to understand that Dave is slime, and then you'll see the value of the Atom group.
Now, another couple months has gone by, and more and more are implementing RSS2.
The point is not what was..
..but who is prepared to help Dave and RSS2 right NOW, and in what way?
Yes, to help RSS2 is to help Dave, personally. Because RSS2 (and weblogging, too, to some) is still Dave's "baby".
So what? like you said!
The user's dunno Dave, they somewhat know what they like, which is common features enabled, which work each and every time without failure. And, since most-a the user's are bloggers, there's a myopia that RSS2's primary benefit is to help bloggers.
Thaz another falsehood-meme.
So you can't really pick the side of the user's, and be against Dave and RSS2 and in favor of Atom, because these are overlapping. (Well, obviously anyone can do whatever they want, but you work against the user's interests in the process. And I wouldn't say the same thing about RDFers, a-tall, btw.)
And, one never knows, but mebbe if Dave saw others working in favor of the directions RSS2 has BEEN going the past year, mebbe he'd decide whether he wants to sit in the hot seat or not. Or whether that seat has room for more than just him.
But I sure DO know, as do you and most everybody, that although Dave has undue influence on the process at present, RSS2 has gone way beyond being all about Dave Winer, except to those in favor of Atom (and, to an extent, Dave himself).
Most everybody knows that, at some level.
Specs and implementations are a tough chicken-and-egg, we all know that also. The implementations are necessarily beyond the control of the spec'rs, which is a good thing for several reasons... Likewise, a better spec will normally lead to better implementations.
It's incorrect to view either as primary, Danny.. But spec'rs will view specs as THE most important, and implementors will view implementations as THE most important.
User ends up in the bit-bucket, as a result, largely because of this.
Ian Hickson writes a recap of the Compound Document Workshop. To quote a little: We had some straw polls; of the 40 or so people there, around 8 said they wanted to work on the work Opera and Mozilla have been proposing recently, and about 11 said...
The first Atom Community Meeting took place on Wednesday 2 June, organised and hosted by Tim Bray. On the agenda was a discussion of whether Atom should go the IETF or W3C route, or both. Tim's notes on the meeting, and the IRC log of the event...
It's about adoption. Developers, 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...