Re: Moving past last call for HTML5

On Fri, 20 Feb 2009, Sam Ruby wrote:
> > 
> > If it turns out that this is one of only a few things that need to 
> > change to dramatically increase the level of consensus from certain 
> > quarters, then it's certainly an area that will change. On the other 
> > hand, if the people objecting to this section also object to most of 
> > the rest of the document, then changing it wouldn't gain us much. Does 
> > that make sense?
> Regarding the question in the last paragraph: not to me.

Ok, let me rephrase it. When there are topics where different parties in 
the working group have radically different mostly incompatible positions 
where the distinction is a philosophical one and not one that can be 
resolved by reference to data or logical argument, as is the case with 
some of the controversy in the introduction sections, I think it is 
reasonable to expect each party to compromise on some of their desires if 
parties compromise in comparable amounts.

I do _not_ think it would be reasonable for one party, for example Larry, 
to compromise on every issue, with another party "winning" every 
controversial argument.

I similarly do not think it would be reasonable for two parties to 
compromise on something if doing so wouldn't actually improve the position 
of the working group. To give an extreme: if someone has the position that 
some particular controversial text should be added _and_ that the entire 
approach taken by HTML5 is wrong, and they will formally object if either 
of these positions fails to be attained (i.e. they refuse to compromise on 
either), then it doesn't make sense for someone with the opposing views to 
accept the controversial text but refuse to change the approach, since the 
net result would be that neither party would be happy.

Does _that_ make sense?

I speak from the position of the person who represented the browser 
vendors on the sXBL conference calls, where two parties had radically 
different needs and in the interest of progress, one party (the browser 
vendors) kept agreeing to compromises because it would help move the spec 
forward. The result was that the spec became less and less like what the 
people I was representing wanted, until we finally reached something that 
we weren't willing to compromise on, and then the process collapsed. The 
result was that we then took the spec onto another track and changed 
almost every compromise back to what we originally wanted, with XBL2 
resulting. I have no interest in seeing a specification go down this same 
road again, with some parties compromising on issue after issue (_whoever_ 
that might be), if it isn't clear that there is a light at the end of the 
tunnel where _all_ the parties are getting something for their efforts.

(And again, this all only applies to subjective things. Where we have data 
or logical argumentation that we can use to drive decisions, that IMHO 
should trump all else; that's what I mean when I talk about not being 
consensus-driven as an editor.)

> This looks like an easy issue to me, but if you want to defer it to 3Q 
> that's you choice.

For what it's worth, I'm not scheduling my work based on how easy it is, 
I'm basing it on how important it is to implementors. Introduction 
sections, even controversial ones, will never be a high priority and will 
always be delayed in favour of normative text. This has to be the case 
because otherwise implementations will diverge from the spec, which is the 
very situation we're trying to avoid.

> > The approach of just ducking controversy doesn't improve 
> > accessibility.
> Time out.  If I felt the "no consensus, no code" approach was viable in 
> anything approximating a reasonable timeframe, we wouldn't be having 
> this discussion.  We are exploring a potential "next step", not a "final 
> destination".

I don't understand. By W3C process, we're not supposed to have any 
remaining issues at last call -- that is, the spec is supposed to as close 
to the final destination as we can make it. How are we not exploring a 
final destination?

Anyway, what I'm hearing from you is that what I should do is continue to 
respond to feedback, naturally including things like Larry's feedback, 
with the intention to be down to zero issues before we want to publish.

What I am unclear on is how we are to proceed beyond that point with 
issues where none of the parties are willing to compromise, assuming we 
have some, since it seems unlikely that we won't. It's also unclear to me 
how I can find out what that list would be. Is the list of OPEN issues a 
list of unresolved issues where no compromise has yet been reached? Would 
it help if, at some future point before October, I started going down this 
list and tried to drive them to resolution myself? Or are we expecting 
this list to have zero items on it by then?

I guess my question boils down to asking about what your expected 
timetable is for these controversial issues.

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

Received on Saturday, 21 February 2009 02:29:27 UTC