Re: Deciding in public (Was: SVGWG SVG-in-HTML proposal)

On Fri, 2008-08-01 at 09:40 -0400, Sam Ruby wrote:
[...]
> I'd like issue 41 to be addressed.  As near as I can tell, the defined
> process is to make proposals, though it seems that every proposal from
> any source gets quickly dismissed.  A point of frustration for me.

I'm pleased to see that much of the frustration was put aside
and that the some interesting arguments around decentralized
extensibility have come out in this thread.

That "defined process" in our charter
  http://www.w3.org/2007/03/HTML-WG-charter.html#decisions
was intended for design decisions; it didn't anticipate
so many scope/requirements issues, i.e. issues of "should
we do this at all?" Indeed, it's frustrating to go back and
forth about who bears the burden of proof or even the burden
to read which proposals or answer which questions.

I think decentralized extensibility is such an issue;
it's useful to explore detailed proposals in order
to understand the costs and feasibility, but we should
invite a certain level of brainstorming and not dismiss
design sketches altogether because of a glitch here or there.

I think it's good that we're discussing many of the
points on the spectrum of decentralization:
SVG and MathML are pretty low on the spectrum;
EXSLT and FBXML are pretty high; canvas is in
there somewhere.

I find this one of the most interesting questions:

[[
Would we be better off if <canvas> had its Apple origin unambiguosly  
on it for the rest of the existence of the Web? Would the Web platform  
be better if it were <apple:canvas xmlns:apple="http://www.apple.com/2004/07/namespaces/webkit/dashboard# 
"> instead of <canvas>?
]]
  -- http://lists.w3.org/Archives/Public/public-html/2008Aug/0019.html

This is also a point that keeps me up nights:

[[
The problem is if they bypass 
community review by shipping the feature before it is taken through a standards 
process.
]]
 -- http://lists.w3.org/Archives/Public/public-html/2008Aug/0021.html

As to the "fundamental assumptions" argument that it's not cost-effective
to revisit the utility of namespaces and such in HTML... that this
was documented as far back as the 2004 position paper by Opera and Mozilla,
  http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html
a big part of the social process of taking on the text of the HTML 5
specification was to write many of the relevant design principles
in the context of this W3C working group
  http://www.w3.org/TR/html-design-principles/

I see a lot of overlap between the 2004 paper and the 2007 design
principles document, but "Don't overuse namespaces" is a notable
exception. I'm not sure there's a design principle about
namespaces that we should add, but we shouldn't be all _that_ surprised
that we missed one or two of the "fundamental assumptions"
in our design principles exercise.

As to the burden of proof/argument... I have spent the last several
years working in XML and Semantic Web circles where
URI based extensibility is the norm, but HTML predates that
and is deployed at a much, much larger scale.

I just associated issue 41 with the "HTML Principles/Requirements"
product; it joins a list of things that weren't in HTML 4
that we're considering for HTML 5.
http://www.w3.org/html/wg/tracker/products/2
I hope we'll choose a somewhat conservative scope of features
to take to Candidate Recommendation and Recommendation, based
largely on implementation experience. So I suggest that the
burden of argument is on those who want HTML 5 to have
a distributed extensibility mechanism, since HTML 4 did not have
one.

I observe that arguing with the editors on parts of the HTML 5
design that aren't yet widely implemented is pretty frustrating.
Ian has little appreciation of consensus (by the way...
the decision to choose him as editor was not made by consensus
http://lists.w3.org/Archives/Public/public-html/2007May/0909.html )
and he has perhaps been too intimately involved with HTML 5
for too long to appreciate the value of due process as the
project matures. Besides... as Ian himself has noted, his
opinion doesn't really matter that much anyway.
I suggest that the parties that need convincing
are the ones building the software we all use... browsers,
authoring tools, content management systems, etc.
If you convince a critical mass of those, I'm sure
Ian will dutifully work out the details of an interoperable
design.

Microsoft has taken the risk of making a proposal in
the form of code; they seem convinced of the requirement
and somewhat open to negotiation about the design.
Opera and Mozilla are pretty clearly
on record against decentralized extensibility.
I'm not sure I have seen Apple take a clear position,
let alone any authoring tool builders, mobile browser
developers, etc. I don't currently see a critical
mass in favor.

As to decisions and escalation... as Ian notes, he makes
zillions of decisions every week or even every day...
and this Working Group as a whole has only made
6 decisions, formally: 4 publication decisions,
the decision to review HTML 5, and the decision
to take on the immediate-mode-graphics/canvas
requirement
 ( see http://www.w3.org/html/wg/#events ).
It's not reasonable to expect all interested parties
to watch Ian's IRC chatter 24x7 so that they can
engage when issues of interest to them come up.
Laura pointed out the escalation to tracker
( http://www.w3.org/html/wg/tracker/ )
and the weekly teleconference, but I can't really
say that's a well-oiled machine yet. I hope we'll
find a better balance with respect to due
process soonish.


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Friday, 1 August 2008 18:26:17 UTC