Re: ACTION-95, ISSUE-65: Plan to publish a new WD of HTML-5

Murray Maloney wrote:
> For what it's worth, I'm almost certain that any HTML 5 Markup Language 
> Working Draft
> would only become normative if it became a Recommendation, which entails 
> a variety
> of process steps that forestall any risk of non-democratic power grabs.

I should note that earlier steps in the process also carry normative 
weight (for example, CR involves a call for implemenation of the 
normative parts of the draft).

>> In my experience with the W3C (mostly interaction with the HTML, CSS, 
>> SVG, and XML Linking working groups), as soon as there is more than  
>> one normative document that applies to a given situation conflicts arise.
> 
> Let's try to do better this time. It is possible to cooperate. The 
> result will be better.

Murray, there was no lack of cooperation in the above situations, from 
what I could tell.  There was a certain amount of "it's the other guy's 
problem", a fair amount of divergent deliverable cycles, and a very 
large amount of what I mentioned above: people not fully thinking 
through the implications of uses of the thing they specified in contexts 
that they hadn't considered.

> One of the lessons that I have taken from the evolution of HTML is that 
> there is no single view that rules them all.

I didn't say there was.  I did say that if you have an expert in 
technology A and another expert in technology B neither one might be 
very good at dealing with the interaction of A and B unless he takes the 
time to really study it.  There is a tendency to assume that A and B 
have been fully specified and that therefore the interaction should be 
obvious.  In practice, this fails to be the case, more often than not.

> It seems that it would behoove us all to try to accommodate each other.

I don't recall suggesting that we shouldn't.

>> In summary, I do think that having multiple normative documents 
>> covering the same ground in any sort of steady state is a bad idea no 
>> matter what our other goals are.  So if we head down that path I would 
>> like to see a plan, with explicit milestones, for leaving that path 
>> (that is, ending up with exactly one normative document covering any 
>> given part of HTML).
> 
> Plans and milestones are reasonable expectations.
> 
> I think you might need to define the terms that you use in the expression:
> "exactly one normative document covering any given part of HTML"
> in the context of the HYPERTEXT Markup Language.

Sure.  Given any question arising in implementation of any application 
working with HTML, the question needs to be answered in one and only one 
normative section of one specification.  If the answer requires 
synthesizing several normative sections (possibly from multiple 
specifications), that's fine, but there must be a unique such synthesis 
capable of answering the question.

In other words, normative requirements must not be duplicated, either 
within a specification or across specifications.  Any time they are, we 
have a quite nonzero probability of the duplicates diverging.

> If it turns out to be a problem in the future, then let's deal with the problems democratically as they arise.

The current approach (multiple drafts both claiming to be normative and 
covering some of the same ground) will become a problem at some point, 
unless we significantly change one or the other draft.  What I am asking 
for is a deadline (in terms of process, not dates) at which we will 
stop, evaluate whether said significant changes have happened, and if 
not reach a decision about how to proceed such as to enforce the 
criteria I described above.

Of course if we get there and there is no problem, so be it, but it 
seems simpler to me to set up a plan now than it would be to deal with 
the situation then, after a lot of work has been invested in both drafts 
and people have become even more emotionally attached to them than they 
are now.  The emotional attachment is already being a problem, from what 
I can tell...

-Boris

Received on Friday, 30 January 2009 21:44:17 UTC