(part 2 in my continuing exploration of what went wrong with XHTML at the W3C)
Okay... it's a week later, and I have a little distance from the original event. The XHTML 2 Working Group had its regular meeting on Wednesday, just as we have for the last many, many years. At that meeting, we continued to make progress on resolving issues so that we can update some of the existing Recommendations and move other documents to Note status (see our Drafts page for what is being worked on).
While we were doing that, we of course were whining a little about the announcement. Mostly because the working group was not really consulted nor informed. Everyone in the group had learned about it from the press, not from the W3C. Yet another example of the masterful mismanagement. Don't get me wrong - we all had heard inklings, but there had been no decision made that we knew about. The FAQ that was published was produced without consulting the working group either. So basically we learned about our future work by reading that document too. Unbelievable.
Despite these (typical) events, I've still got the greatest enthusiasm and confidence in the mission (Dave). No, seriously. I do. The W3C is the worst form of standards production except all the others that have been tried (apologies to Winston Churchill). The model on which the W3C is built is one that makes sense if applied correctly. Get motivated, funded professionals who are experts in their field together and ask them to achieve consensus on the codification of some technology. Then show their work to a broader collection of experts and ensure it makes sense and integrates with the overall architecture. Assuming it does, call it a "standard" and get people to support and use it.
This model is simple and clean. It probably even works when there are relatively few of these groups of experts working on a cohesive set of deliverables (The Open Group is a great example of where this has succeeded by keeping the focus tight). Where it seems to fall down is when the keepers of the architecture lose control. At its outset, the keeper of the W3C vision was TimBL. Sure, he had minions to do his bidding, but in general they were mouthpieces for Tim. As the work of the W3C got more and more complex, the responsibility for the vision was passed on to various groups who were charged with maintaining their bit.
I desperately want to believe there was a long term strategy for the web motivating all the work the W3C's Advisory Committee, Technical Architecture Group, Advisory Board, HTML Coordination Group, etc. were chartering all these years. But I think that by pushing the responsibility further and further down the stack and at the same time getting distracted by other external activities like the WHATWG and the new World Wide Web Foundation, that strategy got miscommunicated or diluted or just lost. In any event, we now have a serious problem.
What's the problem? The organization with the primary responsibility for taking the web forward has two competing sets of activities. There's the browser-centric work - this includes HTML5, CSS, and the Rich Web Client Activity (HTML DOM stuff, Widgets, XMLHTTPRequest etc.). Then there's the web-centric work - this includes XML, XPath, Xinclude, XML Schema, RDF, OWL, etc. And while these sets of activities could be designed to dovetail together, the browser-centric work seems to be ignoring the rest of the work.
I have seen some people argue that the W3C's focus on the semantic web and the XML tool chain has neglected even the most basic maintenance of its (wildly successful) previous deliverable - HTML. I think I can safely say that this is true. Moreover, I am one of the people who helped make it true. The (former) HTML Working Group had responsibility for maintaining HTML 4, and we elected not to update it. It was too much work, and we were focusing upon XHTML, XHTML M12N, XForms, XML Events, etc. We had some members who volunteered to help process incoming comments on HTML 4 and produce errata, but in the end it never seemed to happen. So yeah, I and the rest of the (former) HTML Working Group are culpable.
Thank goodness the Google and the browser vendors came to our rescue! (yes, that was sarcasm). Now we have swung completely the other direction. Rather than focusing upon the future, we are clarifying the past. Oh, and while we are at it, introducing new untested concepts into the specification, sometimes despite there being standard alternatives already deployed. Does this bother anyone else? Surely, just as it is a mistake to lose sight of the past, it is a mistake to forget about the (envisioned, architected, long planned for) future?
HTML5 is here to stay. I get that. But that doesn't mean we have to continue to repeat our mistakes. Ignoring the HTML4 specification was a mistake. Ignoring the XHTML specification(s) is also a mistake. Pretending that the "XHTML5" part of HTML5 somehow continues the evolution of XHTML as part of the XML toolchain is a gigantic mistake. HTML5 has no extensibility model. It has no way to incorporate other public or private grammars into the content model. It has no model to define and connect RDF grammars that would expand the semantics of the language. It has no behavioral rules that describe how user agents must behave that will permit this extensibility going forward.
Right now, today, we need to find the strength to say "no! This is not good enough!". We need to ensure that the extensibility that is the cornerstone of the W3C's efforts to define the future of the web is not removed. Because we all know what happens when you remove a cornerstone, right?
The Infrastructure Shock
2 weeks ago