W3C home > Mailing lists > Public > public-html@w3.org > July 2009

Re: formal objection to one vendor/one vote

From: Sam Ruby <rubys@intertwingly.net>
Date: Sat, 11 Jul 2009 15:40:39 -0400
Message-ID: <4A58EAB7.9090202@intertwingly.net>
To: Shelley Powers <shelley.just@gmail.com>
CC: HTMLWG WG <public-html@w3.org>
Shelley Powers recently made a good faith effort to create a Formal 
Objection[1]; however, to date I have not found a way to treat it as 
such.  The concern is certainly valid, but we need to find a process for 
dealing with the issue, and this post is a part of the process for 
determining the process.

The concern is that Ian made a decision to remove two subsections[2] in 
his draft HTML5 spec in which codecs would have been required and that 
such a decision was widely viewed as a decision by the W3C.  It was not, 
in fact, a decision by the W3C, and as such it is not a subject to a 
Formal Objection.  But I can't escape the fact that the perception 
exists, and is widely held[3].

Before proceeding, I wish to compliment Ian for making a decision.  This 
is not a topic with obvious answers.  On one hand, I believe that 
marketplace should sort out the codecs situation.  On the other hand I 
do not believe that the current draft contains enough information by 
itself to ensure interop.

Ian also took the opportunity to provide some insight[4] into his 
decision making process.  In doing so, he created an impression that he 
did so as Apple exercised a unilateral veto.  I believe that such an 
impression is unfortunate, counter-productive, and not in line with my 
understanding of either W3C or WHATWG processes.  In particular, I 
actually believe that the accepted goal of the WHATWG was two complete 
and bug-free implementations in 2022[5].  I do not believe that Apple's 
participation is required to meet that goal.  In particular, I believe 
that there are at least three implementations today which could form the 
basis for meeting that goal, with required codecs, namely the browsers 
produced by Mozilla, Google, and Opera.  Nor do I believe that Ian has 
talked to anybody who can say with absolute certainty what Apple will or 
will not support by 2022, as I don't believe that such a person exists.

That still leaves the matter of the public impression.  I will start by 
saying that I feel no compelling need[6] to correct the impression at 
this time.  I believe that the correct way to address the mis-impression 
that the W3C Working Group has made a decision is to actually make a 
Working Group decision.  Meanwhile, I am posting this publicly, both on 
my blog and on public-html.  I harbor no illusion that it will be 
sufficient to correct the misunderstanding.  If anybody feels so 
inclined, feel free to refer people to this.

For the Working Group to make a decision, we need something concrete to 
express an opinion on.  Which means that we need some text, be it some 
sort of resolution or (my personal preference) some concrete spec text. 
  My reasons for preferring the latter is that spec text is both more 
durable and less ambiguous than resolutions.  I'm particularly skeptical 
about resolutions that take the form of "I think that somebody (other 
than me) should do the following" in general, and "make the editor do 
this (against his better judgement)" in particular.

At the present time, we (nominally) have two editors[7].  This has been 
a continuing source of controversy, but overall has served us well, at 
least to get us to this point.  It may, however, very well be the case 
that this is not the model that will get us to Last Call and beyond.  We 
now seem to have at least three individuals who have made significant 
efforts to work within this system, and now feel that producing a 
document themselves may be a more productive use of their time:

  * We have Rob Sayer[8] who, as I understand it, is not satisfied
    with the codec decision, feels that the current draft contains
    inventions that would be premature to standardize at this time,
    and feels that the spec contains a number of places where it
    places burdensome limitations on authoring behavior without
    sufficient corresponding benefits to browser vendors.

  * Second, we have Steven Faulkner who in Thursday's call[9]
    indicated that he was intending to draft a spec, presumably
    addressing accessibility issues including alt text and summary
    attributes.  I'm hopeful that this will ultimately address ARIA.

  * Third, we have Manu Sporny who indicated[10] that he will be
    producing a spec that addresses uses cases not addressed by
    microdata[11] (and in particular, incorporates RDFa).

So, ultimately, we may end up this month with four separate 
specifications.  If this comes to pass, we may need to adopt naming 
conventions like the IETF does, like draft-author-name.  If we do so, I 
am fully confident that the W3C has the technical chops necessary to 
make this a smooth transition via HTTP redirects.

It is also my experience that such a situation won't last long.  Some 
efforts may merge, some may lose interest, and some may never make to 
the point where they have a first draft ready for consideration.  In 
fact, we could end up determining that a benevolent dictator[12] is the 
worst form of government except for all those others that have been 
tried (with apologies to Sir Winson Churchill[13]).

If, when we get to the point where we are ready to go to Last Call, a 
number of competing proposals still remain, then we will have a vote.  I 
fully recognize that a number of people would prefer technical 
superiority to win out over what they view as mere popularity contests, 
and these people are certainly encouraged to cast their vote in this 
manner.  I will simply note that it is quite possible for two 
intelligent individuals with similar backgrounds and experience can come 
to different conclusions when presented with the same data.  And we can 
all name standards that are "technically superior" that few follow.  I, 
for one, would rather take part in the creation of a standard worthy of 
loving parody[14] by the likes of Clay Shirky than to produce another 
such standard.

Returning to Shelley's objection (even though it may not be end up being 
recognized as being a Formal one), I beg her indulgence as I would like 
to see how these various efforts play out in the upcoming weeks.  Should 
one or more succeed and/or Ian changes his position, I would hope that 
she would consider voluntarily withdrawing her objection at that time.

Meanwhile I've reopened issue 7[15]:video-codecs and opened issue 
75[16]:microsoft-review.  I'll be looking for owners for those two issues.

Related reading: authority[17], access[18], policy[19], support[20].

- Sam Ruby

[1] http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html
[2] 
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020620.html
[3] 
[http://tech.slashdot.org/story/09/07/02/184251/Browser-Vendors-Force-W3C-To-Scrap-HTML-5-Codecs
[4] 
[http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020804.html
[5] http://www.whatwg.org/specs/web-apps/current-work/TIMETABLE
[6] http://xkcd.com/386/
[7] http://dev.w3.org/html5/spec/Overview.html
[8] http://lists.w3.org/Archives/Public/public-html/2009Jul/0135.html
[9] [http://lists.w3.org/Archives/Public/public-html/2009Jul/0367.html
[10] 
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0067.html
[11] 
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0038.html
[12] 
http://realtech.burningbird.net/semweb/accessibility-and-microformats/#comment-471
[13] 
http://wiki.answers.com/Q/Who_said_democracy_is_the_worst_form_of_government
[14] http://www.shirky.com/writings/evolve.html
[15] http://www.w3.org/html/wg/tracker/issues/7
[16] http://www.w3.org/html/wg/tracker/issues/75
[17] http://lists.w3.org/Archives/Public/www-archive/2009Jun/0132.html
[18] 
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0017.html 

[19] 
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0018.html 

[20] 
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0019.html 
Received on Saturday, 11 July 2009 19:41:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:05 UTC