Re: ISSUE-76: Need feedback on splitting Microdata into separate specification

There are some points here that I strongly disagree with and that I think 
are pretty fundamental to many of the decisions that the working group 
will need to make in the coming weeks and months, so I think it might be 
worth putting these issues as a meta question to the group, to give me 
guidance (as one of the editors of specs that this working group is 
publishing) on what kind of policy I should be following.


On Fri, 4 Dec 2009, Shelley Powers wrote:
> 
> It's easier to get a specification cleanly finished when its focused on 
> the technology it's supposed to be focused on.

HTML5 _is_ focused on the technologu it's supposed to be focused on.

Even if we grant for the of argument the premise that it is not, it is 
still the case that the WHATWG has reached a later milestone than the 
HTMLWG, despite the "lack of focus" you infer. Therefore it seems to be 
untrue that the current development model will prevent progress: it is in 
fact arguably the requests that the specification be more "focused" that 
are, in part, preventing that same progress in this working group.


> It's easier to integrate the specification with other specifications, if 
> it's focused.

What do you mean by "integrate" and "focused" in this context?

HTML5 and a number of other specs (XHR, Origin RFC, Sniffing RFC, Web 
Sockets, CSSOM, CSSOM Views, Web Storage, etc) are working closely 
together as it stands today. It doesn't seem to have been a problem.


> Just the same as applications are cleaner, and better when they're based 
> on modularization.

I do not think this statement is a truism.

For specs in particular, I'd go as far as saying that it's flat-out wrong. 
Modular specifications have historically in the W3C been significantly 
less successful than "monolithic" specifications. Consider CSS3 vs CSS2, 
or the XHTML Modularisation specifications vs XHTML1.0. I'm not aware of 
any examples where the opposite is true (where a modularised set of specs 
has been more successful than its monolithic counterpart).


> When you open the door to everything under the sun, the spec will never 
> be finished.

Ironically, again, the spec is closer to being finished in the working 
group that does not espouse the position you are advocating. Certainly 
from an editing perspective having more smaller specifications is more 
costly to my productivity than having one single specification.


> More than that, it will always have problems getting accepted by the 
> wider community.

HTML5 is having no trouble getting accepted by the wider community. In 
terms of acceptance by the wider Web authoring community, and in terms of 
acceptance by user agent vendors, it is one of the most successful 
specifications the W3C has published in the past five years. In fact the 
main communities with which it has been finding trouble getting acceptance 
are the much smaller standards committee communities such as the TAG and 
PFWG, not the wider community at all. (Smaller in terms of raw numbers, 
compared to the the WHATWG mailing list subscription count, at any rate.)


> Microdata doesn't need to be in the spec [...]

Microdata "needs" to be part of HTML5 because it is part of the language. 
Taking Microdata out of HTML5 makes about as much sense as taking out 
<h1>, <p>, or title="", IMHO.


> What's another thing we know from application development? It's easier 
> to add at a later time, then it is to remove.

This indicates a lack of familiarity with HTML5's development over the 
past few years. We have dropped numerous sections with far less effort 
than they took to be written. Repetition templates, <datagrid>, form 
prefilling, space-separate form="", peer-to-peer TCPConnection, the 
<eventsource> element, <datatemplate>, <font>, the entire "out of scope" 
section, several introduction sections... Not to mention the numerous 
sections that were split into other specs, such as XMLHttpRequest, Web 
Storage, Web Database, Web Workers, Web Sockets API, Web Sockets protocol, 
the Server-sent Events API, Content-Type sniffing, and URL parsing.

No, if there's one thing we _do_ know about HTML5, it's that we've had no 
trouble dropping features. In fact the _only_ exceptions I know about are 
the ones that you mentioned, and the only reason we've had trouble 
dropping them is that you and others have objected to dropping them 
(summary="", for example). I presume that wouldn't apply here, since you 
are specifically _asking_ that we drop them.


To return to the point I was making at the top of this e-mail: IMHO, the 
issue boils down to this:

   Is it the group's opinion that specification length should be one of 
   the working group's primary concerns?

   Or is it the group's opinion that the length of the specification 
   should be at most a secondary concern?

Could I ask the chairs to consider putting this question to the working 
group? If we have a strong concensus one way or the other, we could save a 
lot of time (for example, if the working group thinks many small specs is 
better than one spec, independent of the content of the specs, then I 
should just split the spec up into smaller parts now, and save us the 
trouble of fighting over each subpart in turn over the next few months).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 4 December 2009 14:47:01 UTC