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

Nikunj Mehta <nikunj.mehta@oracle.com>, 2008-11-18 17:09 -0800:

>  On Nov 17, 2008, at 5:36 PM, Ian Hickson wrote:
> 
> > On Mon, 17 Nov 2008, Nikunj Mehta wrote:
> >>
> >> What Ian considers Platform core [1] as listed in [2] includes a wide
> >> variety of things that don't have much to do with HTML at all. SQL
> >> (5.10.2) and unstructured storage (5.10.1) are good examples. The only
> >> reasons for keeping these parts in the HTML5 spec that I have seen are
> >> that these pieces are stable and the same editor would be working on
> >> these sections as the Platform Core. Neither sound good enough reasons
> >> to me.
> >
> > They're not particularily good reasons, but splitting those two parts up
> > would delay progress by a year or more, and that is unacceptable IMHO.
> 
>  Sorry but Hixie's opinion is not what decides the matter here.

True -- what would help more to decide the matter would be if we
had somebody step forward to take ownership of a particular part
of the current draft and edit it as a separate document. As you
noted in a previous message, "many decisions are based on
available editors and required expertise." See Dan's earlier
comments about "he who does the work...".

Especially in the absence of any additional editors, it does
matter quite a bit what Hixie's opinion is, since at this point
he's the only who's written (and is maintaining and updating) an
actual draft for most of the things that others have suggested
should be split out (e.g., structured client-side storage). He's
made the assertion that it's a significant amount of additional
work for him himself to take any given part of the current draft
and maintain it as a separate document. To me, it doesn't seem
particularly reasonable to expect that he should choose to create
additional work for himself -- or that the working group should
try to compel him to -- in order to achieve an outcome that he and
others here have questioned the value of -- that is,
modularization of the current into separate physical documents,
but one editor still maintaining it all.

If your answer were to be that splitting the spec into separate
physical documents would be a step toward getting additional
editors on board to work on them, I guess I'd say an even shorter
step would be interested potential editors to do the work of
splitting out whatever part(s) they're have interest and expertise
in, and then making those available to the group for review.

>  This just 
>  totally tosses out my understanding of the W3C process out the window. IIUC, 
>  the role of the editor is to take technical inputs about the specification 
>  and weave it together into a coherent whole,

That certainly seems to me to be pretty much what Hixie has been
doing for the last 5 years or so now that he's been working on the
various parts of the current HTML5 draft (including for more than
3 years before our current HTML WG existed).

There is a history behind that way the current HTML5 draft evolved
and the environment it evolved in and that led to the current HTML
WG being chartered. My personal take on trying to document some
significant milestones in that history is here:

  http://esw.w3.org/topic/HTML/history

I can't claim it's an objective or complete record in any way.
It's just an attempt at trying to list out some of the events and
interactions that got us to where we are now (or at least to where
we were are the time the group was chartered).

It seems worth mentioning here that Hixie did not become the
driving force behind the work on this specification because
somebody else gave him responsibility for working on it. It came
about because he took initiative on it and responsibility for be
it at a time when many others questioned whether it was even worth
doing (and in some cases were focusing on alternative approaches
to standards related to client-side technologies that have so far
not had much success at getting implementation support in
browsers) -- and kept at it working on it over several years, full
time, in close communication with implementors to make sure the
end result would be something that aligned with implementation
realities and that had some practical chance of actually being
implemented.

I think all of us would like to see others take similar initiative
and do the work of writing up drafts for parts of the spec they'd
like to see split out (or for drafts that offer alternative specs
to what's in the current HTML5 document), and to commit to the
long-term process of doing ongoing direct discussion with
implementors and others about the implementation details, and
making refinements based on those discussions.

>  not also to define the process 
>  and make decisions. The former is done by the W3C/WG and the latter by the 
>  WG chairs based on consensus/up down vote.

I think it is a mistake to see this as simply a battle between
Hixie and consensus. (Though I will admit that I don't think some
of Hixie's comments about his views on consensus have been a big
help here.) Hixie in part represents a community; in large part, a
community that was active in supporting and participating in the
HTML5 work for quite a while before it was (re)integrated into the
W3C and in which a number of implementors are very actively involved.

The decision-making process that takes place with those
implementors around the parts of the spec that relate to browser
implementation behavior is not one of Hixie unilaterally making a
decision about what he thinks is best. In fact, there are plenty
of times when he's been overruled by implementors. I think most
people in that community find the decision-making process that's
been used around those parts of the spec to be working relatively
well. A number of them have spoken up on here repeatedly to say
so. That doesn't mean they're all completely happy with it -- I
think a lot of people would prefer we had some additional editors
involved in working on parts of the spec and managing decisions
around them -- but that said, I certainly don't think anybody from
that community would not want to see that process replaced by a
simple consensus/up-down voting system. 

Anyway, such a voting system would ultimately not be effective at
all for managing decisions around browser implementation details
in the spec, because the implementors would simply just end up
ignoring the spec if it did not align with what they were willing
and able to actually implement. In that respect, I guess it could
be said that they have a kind of collective de facto veto power.

But all that said, it's not at all clear that process is the right
one to use for managing decisions about all parts of what's in the
current draft. In particular, neither browser vendors nor any
other group has any kind of veto power about authoring-conformance-
only parts of the spec that don't relate to browser implementation
behavior, and it is certainly imaginable that the group could use
a different decision-making process to manage decisions around
those authoring-conformance parts.

>  BTW, where /is/ the HTML WG chair 
>  in this period of tempest?

Noting that there are two current co-chairs in this group: Chris
Wilson and myself, which particular period of tempest do you mean?
If you mean the flare-up from this particular thread, what sort of
response from the chairs are you expecting? As far as I can see,
there really has been no new information in thread than what we
had on hand during the very first discussion we had on the first
day of our face-to-face meeting last month:

  http://www.w3.org/html/wg/f2f/2008-10/#split-talk

Probably the most significant thing that's happened since then to
actually help us move forward was that Hixie took time to write up
his take on a detailed evaluation of what parts of the current
draft could potentially be split out and taken on by separate
editors, along with an assessment about what level of effort would
be needed to maintain each of those:

  http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html
  http://lists.w3.org/Archives/Public/public-html/2008Oct/0128.html

And as you can maybe imagine, I've had more than a few discussions
off-list with individuals and representatives from a number of
organizations, with the goal of getting some commitments of
additional editors. Some of those discussions are ongoing, but so
far they obviously have not yet led to particular people stepping
forward with drafts or making any public commitments to do so.

I guess it would also be fair to say that I think additional (or
even alternative) leadership in the group would not be totally
unwelcome. I've talked off-list with people who have experience
elsewhere in producing successful standards about the possibility
of stepping in to help with guiding the work of the group. But we
don't exactly have people lining up to volunteer for that either.

The draft markup spec I put together is in part an attempt at
trying to lead by example a little -- in that there has been some
potential need expressed for a separate language spec without a
focus on browser implementation details, and nobody else had
stepped forward to produce a draft to try to address that. So I
figured I would give it a try myself. I hope that in part it helps
to give others some encouragement to produce separate/alternative
drafts for some of the others spec sections that we've all be
discussing -- or even another alternative draft for the
language/markup spec, if they think the one I put together is too
far off the mark to be useful.

Anyway, just to get back to noting what you wrote about this being
a period of tempest: Depending on how you look at it, this
particular tempest has been going on for a number of years now,
and we are in the midst of dealing with some consequences of
decisions that can be seen as having led to it.

Take a look at the events in http://esw.w3.org/topic/HTML/history
in 1998 that related to whether XML should have draconian error
handling; in 1998 and 1999, decisions that were made then about
whether to extend and maintain the core HTML language further; or
in 2002, the decisions to work instead on a replacement for HTML
and some related specs that weren't backwards-compatible with
existing browsers and Web content and that browser vendors did not
see as aligning with implementation realities and market
realities; the decision to have a workshop on Web Applications in
2004 that had the effect of further alienating browser vendors and
moving work outside of the W3C...

I think the period of tempest we are in can be seen in part as a
consequence of some decisions that led to the work on HTML5
starting outside of the W3C, and that led to a community being
formed around that work while it was only being done outside the
W3C, with a relatively successful (as far as implementation
success) decision-making process being adopted to guide the work.

And then the W3C as a community got re-involved in the work
alongside the community that had been supporting it all along
during the years in between, and it's now become clear that the
norms of those two communities and the goals of some members of
each are not always well aligned. I think we can do more to try to
bring them into closer alignment, though we're never going to
smooth out all the differences.

Another reason I put the draft markup spec together was with the
expectation that it could end up being something that would help
to encourage and facilitate discussion and closer participation in
decision-making from people in the group/community who aren't
participating in discussions and decision-making around the parts
of the spec that deal with browser-implementation details --
including people in the community, outside of the group, who have
basically dropped out/ tuned out from the group's discussion a
long time ago because they've not be happy with the focus of the
work, or with the process, or the list culture, or whatever.

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/

Received on Wednesday, 19 November 2008 09:26:20 UTC