Re: Why "Platform Core" and "HTML5" are in the same spec

On Nov 17, 2008, at 6:43 PM, Nikunj Mehta wrote:

>
> On Nov 17, 2008, at 5:36 PM, Ian Hickson wrote:
>>
>> It's the "Priority of Constituencies" principle.
>
> My reading of the principle actually leads to the opposite inference  
> - that long term effects on users and authors trump the convenience  
> or expediency for spec authors.
>
>>
>>
>>  http://www.w3.org/html/wg/html5/principles/#priority-of-constituencies
>>
>> Concerns of the spec authors (my having time to do the actual  
>> editing, in
>> this case) are higher in priority than theoretical correctness of  
>> design
>> (having the "right" split between spec components).
>
> Sorry I just don't get this. Can someone show me the inference chain  
> from this principle to what Ian says above?
>


"In case of conflict, consider [...] specifiers over theoretical  
purity."
"...costs to authors of the spec itself, [which] should be given more  
weight than those proposing changes for theoretical reasons alone."

Premise: Splitting the spec is a change which is primarily for  
theoretical purity, or at least it does not have major effect on  
users, authors or implementors.
Premise: Splitting the spec would have a significant cost in terms of  
time of the editor of the specification and others.

--> Thus, splitting the spec would improve "theoretical purity" at the  
cost of extra work for the "authors of the spec itself".

This argument assumes that splitting the spec (without otherwise  
changing the requirements it imposes), would not materially benefit  
end users, content authors or implementors. As an implementor, I would  
say it is at best a wash; more granular specs are helpful, but if  
there are complex interactions between the specs, then the net cost is  
greater. I think end users are unaffected since the vast majority do  
not read specifications, and in any case doing so does not help them  
in any way to interact with sites. I think authors may benefit from  
some sort of authoring guidelines, but it's not clear to me that  
making such a document a normative spec helps them more.

So I think Ian's invocation of the principle is correct.

Regards,
Maciej

Received on Tuesday, 18 November 2008 03:07:40 UTC