The topic this time around was intriguing. Mike Smith released a document called HTML5: The Markup Language. Should it be a normative specification, or merely an informative document? That is, should it help the Web Community by being one of the definitive references on HTML5 or should it merely be an informative document for people wishing to learn more? Also, who was the intended audience?

Soon after it was released, it was received with cautious optimism, but also some confusion. Was it for authors (who would write web pages), or for implementers of tools? Within the listserv, a debate raged. A markup specification devoid of parsing information, processing model and APIs was not useful or desirable, some argued, since invariably they were always used together on the Web. Moreover, making a single schema normative (as HTML5: The Markup Language initially did) prevented modification in the name of conformity. Mozilla posted what seemed like official positions to the listserv. Folks working on WebKit also stated their opinion that the document should not be normative.

At stake here was also what should be done about the larger HTML5 specification, formally called HTML5: A Vocabulary and Associated APIs for HTML and XHTML (but informally called The Kitchen Sink Spec., with affection and grudging respect, of course). How should the big specification be managed, and what should be done to modularize it? Could other editors work on parts of it, other than Ian Hickson? In the long term, was One Editor / One Spec. tenable? At least some suspicion about control issues must have existed, since not everyone’s goals were voiced in the open. And of course, there was the view that in order to be useful at all for some definition of “intended audience” HTML5: The Markup Language needed a bit more of the Kitchen Sink in it.

Such debates rapidly reveal two (or two-ish) camps. Although people working on Mozilla appeared to speak with authority on the matter of the specification, the fact of the matter is that at Mozilla, consensus isn’t unanimity. In general, we’re likely to question why an official response is being solicited on votes (and voting within the HTML5 working group is itself contentious). Naturally, modularizing a big specification such as HTML5: A Vocabulary and Associated APIs for HTML and XHTML is probably desirable. Note, for example, how long it takes your browser to load the Kitchen Sink Specification. Ian’s taken a crack at determining what could be split out, and some progress has been made on that front — Web Workers, for example, is now it’s own specification under the Web Applications Working Group.

HTML5: The Markup Language is a useful document, and makes for interesting reading. It’s status, however, remains controversial (normative or merely informative?). Time will tell, of course, how specifications bloom.