L. David Baron wrote: > The above document says: > > # The single greatest complaint heard from the standards community > # concerning the development of HTML5 is that it has not allowed > # for the scientific process. > > I strongly disagree with this statement. A key part of a scientific > process is that the starting point is evidence. I think the > development process of HTML5 gives arguments based on evidence more > weight than any other W3C work I've been involved in, and has put > more effort into gathering relevant evidence than any other W3C work > I've been involved in. This is a good thing.
Hrm, that paragraph is problematic, others have had the same reading as you have on it as well, which is not the message that I had intended. Granted, it's meant to be an introductory paragraph which I spend the rest of the document elaborating on, but perhaps it needs to be revised. It's not the 'gathering of evidence' that I find problematic - quite the contrary, I think that's a great way to deal with some these issues and it certainly has helped solve some rather hairy disagreements in this community. It's the unevenness in the ability to directly contribute to the specification that is the "walled garden" that I take issue with: """ Throughout history, the ability to openly contribute ideas, scrutinize them, and form consensus around those ideas has been shown to produce the most desirable outcomes. HTML5 is currently a walled garden that must be opened to the greater standards community in order to ensure a stable framework for the future of the Web. """ So, addressing those point-by-point related to how the WHAT WG operates: contribute ideas: great! scrutinize them: wonderful! form consensus: fail (but that's what the W3C is for, right?) produce: fail (unless we don't want to scale the community) Ian is really the only one that is actively allowed to produce anything of significance in WHAT WG. In general, if he doesn't agree with you, it doesn't go in. To put an HTML5+RDFa proposal together, I had to go outside of this community. I think it's fair to say that one needs to have a pretty significant chunk of time on their hands as well as technical chops to make a contribution to the HTML5 specification. To understand why this is viewed as an issue, we can look to the Microformats community, which has roughly 1,300 mailing list members. Everyone is able to contribute to the main product of that community: The Microformats wiki. Why isn't it the same in this community -- a community that prides itself on being open to everyone? To approach the issue from another angle, we have roughly 1,000 members on this mailing list and could have close to 1 billion people[1] that could be using some form of HTML by 2012, a number of those are web developers (read: a huge developer base). The Linux kernel mailing lists have close to 30,000 members[2], and I don't think it's a stretch to say that there are fewer kernel developers in the world (read: small developer base) than there are web developers and designers. So, I've been wondering about the 30:1 discrepancy. Sure, the WHAT WG has been more successful in getting members than HTML WG... but what's keeping more people from joining? I'm asserting that it has something to do with developers not feeling like they can make a difference. We don't give anybody the impression here that they could directly impact the specification if they so desired. Our "scientific process" isn't open for all to participate at every level of the community. I can git clone the Linux kernel, mess around with it and submit a patch to any number of kernel maintainers. If that patch is rejected, I can still share the changes with others in the community. Using the same tools as everybody else, I can refine the patch until there is a large enough group of people that agree, and implementation feedback to back up the patch, where I may have another chance of resubmitting the patch for re-review. This mechanism is a fundamental part of the community. I'm going to state that again, because that is the point I'm making here: The ability to directly affect change at all levels of this community by anybody that chooses to do so should be behavior that we should be supporting, not stifling. The process that we have favors a select few and forces the rest into being casual observers. > Regarding the section "Action: Splitting HTML5 into Logically > Targeted Documents", I agree that there is value in splitting the > specification. However, I see significant danger in the way you > propose to split it: separating the specification of what is > available to authors and what should be implemented means the > specification risks promising to authors what cannot be implemented, > or cannot be implemented at a cost proportionate to the benefit (as > HTML4 did in a number of places). I may have not done a good job of expressing the purpose of microsections. The purpose of microsections would be to create as much language that could be re-used in each document as possible. Take the <progress> element for example: http://www.whatwg.org/specs/web-apps/current-work/#the-progress-element Web Developers, in general, don't care about the "User Agent Requirements" parts of that section, which constitutes almost half of the content for the progress element. That is, they don't tend to care (in general) about how the browser does what it does. Similarly, people that are creating user agents tend to not care about examples (in general) and would like to know more about the DOM Interface. They would probably rather see examples of how to use the element correctly. So, we have 3 possible microsections: progress-element-introduction progress-element-ua-requirements progress-element-examples These microsections could be used to generate two separate documents from the same source: HTML5: The Language - Syntax and Semantics, would contain * progress-element-introduction * progress-element-examples HTML5: Parsing and Processing Rules, would contain * progress-element-introduction * progress-element-ua-requirements HTML5: Ian Hicksons Specification, would contain * progress-element-introduction * progress-element-examples * progress-element-ua-requirements > I'm a little bit puzzled by the inclusion of the section "Problem: > Partial Distributed Extensibility": it seems to be a technical > issue (although a far-reaching one) in a document otherwise about > process issues. I'm not sure it belongs in this discussion. Other reviewers of the document had said that as well. Perhaps it is not desirable to talk about it in this discussion (which is about process)... but I thought it should be mentioned (and will be brought up in the coming months). I think that there are enough people that care about it to author some spec language to guarantee that round-tripping between HTML5 and XHTML5 is possible. That is, that xmlns: is preserved in the DOM in HTML5. Although, you're right, that's a discussion for another time. > Finally, regarding the section "Problem: Disregarding Input from the > Accessibility Community". I think some of the input that has been > ignored or has been felt to be ignored is input that is difficult to > act on. I agree with the majority of what you had to say. The issue is that, once again, the WAI community was unaware or felt like they were not being given the opportunity to affect change. It's a break down in communication on both sides. WHAT WG has not been clear about what we require, or we haven't made it clear to WAI. There are at least 8-10 people in WAI that are confused about why they are being repeatedly rejected - perhaps they're emotionally tied to their solutions, perhaps WHAT WG doesn't get what they're trying to accomplish. Those possibilities are beside the point: There is no easy mechanism for them to edit the specification, and until recently, they were under the general impression that Ian was the gatekeeper for the HTML5 specification. They should be able to edit /something/ lasting, publish it for review, and rise or fall on the merits and accuracy of their specification language. They are not being given the opportunity to do so. I hope this helps clarify some of the positions that the paper was attempting to express. It wasn't meant as an attack on the WHAT WG - it was meant as a feeler document to see how this community would react to the proposed changes. That is, it's good to get feedback before I spend the time (and money) to implement the changes (some of which we'll conclude are unnecessary). -- manu [1]http://img132.imageshack.us/img132/2988/27062201.jpg [2]http://vger.kernel.org/vger-lists.html -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: Bitmunk 3.1 Released - Browser-based P2P Commerce http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/
