Renamed topic: focus and length of HTML5, was: ISSUE-76: Need feedback on splitting Microdata into separate specification

Ian Hickson wrote:
> 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.
> ...

Indeed.

> 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 
 > ...

He who defines what a milestone is...

> 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.

I guess it depends on the definition of "progress". If it means 
"approving what the editor wants", then yes, the HTML WG isn't as good 
in it as the WHAT WG. If it means "coming up with a decent spec", the 
result may be different.

>> 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.

You mentioned a lot of specs that are separate from HTML5. So this seems 
to support the point that modularity is good.

> ...
>> 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.
> ...

Increasing the number of specs doesn't necessarily mean that the number 
of specs *you* edit need to increase. (and yes, we had that discussion 
before)

 > ...
>> 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.
> ...

Sorry, that doesn't make any sense at all.

First of all, microdata is truly optional; it's not part of HTML4, and 
it's not in actual use except in experiments. How can you say "it's part 
of the language" then? Unless you mean "it's in the spec, so by 
definition it is part of it".

If we'd buy that argument we'd have to re-open lots of discussions about 
other features such as RDFa, @profile, whatnot.

>> 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.
> ...

One difference is that these were removed *before* LC.

>...
> 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).

I agree that this is a good question to ask. But note that this is not 
only about the granularity of the spec, but also about which parts we 
really want to LC as the thing called "HTML5".

Best regards, Julian

Received on Friday, 4 December 2009 15:12:53 UTC