intertwingly

Brendan Eich: Standards often are made by insiders, established players, vendors with something to sell and so something to lose. Web standards bodies organized as pay-to-play consortia thus leave out developers and users, although vendors of course claim to represent everyone fully and fairly.  I’ve worked within such bodies and continue to try to make progress in them, but I’ve come to the conclusion that open standards need radically open standardization processes.

The W3C HTML Working Group needs a CarterPhone.  Clearly, Brendan is talking about ES4, but the issues he brings up are general.

When I was growing up, all phones I ever used were the property of AT&T.  It takes a totally unified system to make it all work. One system. AT&T.  Yes, that gave us Princess Phones, but not answering machines, fax machines, cordless phones, or computer modems.

What are the four format freedoms that correspond to the four net freedoms?

In the summer of 2000, the notion of defining RSS as a monolithic entity was put forth.  “Interesting ideas” once defined in namespaces apparently included rdf:about (now guid) and dc:date (now pubDate).  Meanwhile, some barnacles like skipDays and cloud got included.  27 months later, RSS 2.0 got namespaces, and data like dc:creator, content:encoded, and slash:comments (all which already had long histories with RSS 1.0) could now flow through that format.

Scope Issues

Dan Connolly: Of course, it would be easier to publish the spec right away if the spec took a much more conservative position on issues such as videoaudio, immediate-mode-graphics, and offline-applications-sql.

Apparently reasonable people disagree about whether these things are included in the charter.  That doesn’t mean that there aren’t good arguments to be made on both sides — in fact, that’s exactly what you would expect in a situation where reasonable people disagree.

One way to address this would be to fix the charter, though many have argued against that, fearing rats the size of lions.  Oh my.  Another way to address this would be to jettison for the moment features which don’t yet enjoy consensus — in the interest of enabling forward progress now.  Predictably that hasn’t gotten much traction yet either.

And yet talk about distributed extensibility goes nowhere.  Nearly four months later it is still on my list of things to look at; when I have time.

Why do I get the feeling like I am faced with an attitude of “It takes a totally unified system to make it all work. One system. HTML5”?

Like Brendan believes is true for ES4, I believe that what we really need here is a radically open standardization process.  The two standards are quite different, so different solutions may be in order.  In the case of HTML5, I believe that a smaller spec which focuses on two things: fixing HTML4 (includings things like well defined error recovery), and setting the basis for separate (often overlapping) groups to work on things like canvas.  No, I’m not suggesting that canvas needs to be in a namespace, but just that the rules for extending HTML be written down.

In such an organization, things could always be flowing.