Re: Adding Web Intents to the Webapps WG deliverables

* Ian Fette wrote:
>I don't get it. The overhead of getting all the other browsers to join the
>WG you mention is just as high, especially when there's no indication that a
>number of browsers intend to join that group. I don't think it's a random
>process question, I think it's rather fundamental issue. If we agree that
>the right way forward is to create a new WG for each API [...]

The idea is to record in charters what working groups are expected to
deliver to allow proper review, planning, allocation of resources, and
so on. A coarse characterization will make those things difficult, and
a very narrow characterization will make taking up new work difficult.
Surprising new requirements come with more overhead than things that
have been anticipated well in advance; but that's not "one WG per API".

I note that these processes are not designed to minimize hurdles for a
handful of browser vendors, but for broad consensus and high quality
deliverables that arrive reasonably predictably. That requires parties
to synchronize. Removing synchronization pressure leads to what we have
with the Web Applications Working Group, which after six years has a
XMLHttpRequest test suite consisting of nothing but "There is a good
chance a test suite for XMLHttpRequest will be placed around here" and
no XMLHttpRequest specification to show.

There are drafts and submissions, but it would seem people regard this
state of affairs as good enough and so there is little pressure to pull
things together and push out a proper release. And I note the same goes
for earlier stages aswell, the process being largely unpredictable as
it is driven by "when one or more of a handful people feel like it", it
becomes very difficult for out-of-the-loop parties to meaningfully en-
gage in the process. If you mostly want to sanity-check reasonably com-
plete documents, which should you review? The first Last Call? Second?
Third? Fourth? Fith Last Call? Third Candidate Recommendation? When can
we expect a reasonable test suite to verify everything is interoperable
enough to remove vendor prefixes? Seven years? Oh there is a couple of
Webkit specific tests somewhere in the source tree, we think this is
good enough so we just throw it out there with no proper test suite?

It's not a matter of "this has more overhead than that", but a matter
of what we, all of us, want to get out of the standards process, and
what of that can reasonably be achieved within constraints we have. It
may be for instance that "we" are moving too fast, and should not work
at this point on "Web Intents" and instead use what limited resources
there are to finish some of the pending work first. It may also be we
don't care about this silly business with Recommendations and Tests so
this can easily be added. Or we might find that we need to invest more
resources so we can do more things in parallel. Or something else. But
without an understanding what the process should produce and support,
which we quite clearly lack, at least collectively, there is no point
in arguing that process A is better than process B.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 20 September 2011 21:28:06 UTC