W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Another look at the Proposed Design Principles

From: Dailey, David P. <david.dailey@sru.edu>
Date: Sat, 28 Apr 2007 22:18:52 -0400
Message-ID: <1835D662B263BC4E864A7CFAB2FEEB3D258BE3@msfexch01.srunet.sruad.edu>
To: <public-html@w3.org>

Just as the Proposed Design Principles (hereafter referred to as PDPs - not to be confused with the DEC product of that name) have started to soften a bit in response to community input, my own opposition to them (as noted in [1], [2], [3], and [4] ) has started to soften a bit as well. 

 

It would be nice to save the chairs what Dan Connelly refers to as the expense of "decisions over the objections of some parties." [5]   Maybe consensus is possible -- who knows?  I will argue shortly that consensus on all matters related to extensions of the charter is quite important, since the PDPs represent rather fundamental statements of purpose for the activity of the WG.

 

It looked for some weeks, and I think Maciej and I both rather assumed, that objections to the PDPs were held by a very small minority (we even joked about it a wee bit). Subsequently, it would appear, though, that enough others spoke up [6], [7], [8], [9] that some mutation of those principles has, in fact, become appropriate:

 

* I am pleased to see attempts to revise the language of "Don't Break the Web" as recommended in [2] and [9].  

 

* There has been clarification offered on several of the issues. 

 

* Explanatory examples have been provided for many. 

 

* Attempts to address some of the complaints about ambiguity in PDPs have been made. 

 

Not all the issues that have been publicly disputed have been marked as disputed, though it appears that those advancing the PDPs may not feel that every individual reaction to the PDPs must result in a change - and that is understandable (from at least some perspective emanating from some possible world and we do represent, after all, a wide world). The criterion for establishing "what represents a dispute" seems a bit unclear, however [10].

 

A. Why do we need design principles?

 

The cited reasons to have design principles seem to consist of two major reasons:

 

1. as cited in the document itself [11]

 

    These design principles are an attempt to capture consensus on design 

    approach [...]

 

2. in various clarifications (e.g.,  [12]) the rationale has been explained as follows

 

    If we don't come to any agreement on goals and design approach, then we will  

    find it impossible to make productive progress on a spec.  We'll end up re-

    arguing the underlying issues each time we hit a specific point of 

    disagreement.

 

Both are things I think most people here would agree with. In fact, I'll wager a handful of virtual beans that a straw poll of the membership would provide unanimous agreement with the motivations of #1 above. It would almost warrant its own design principle:

 

    1a. Let us try to find whatever consensus does exist and work from there to 

    form a set of design principles.

 

I would strongly support such a point of view. It is what I've referred to as the descriptive approach (rather than the prescriptive approach). On the other hand, if it is presented as 

 

    1b. Here are the design principles we have recommended. Majority rules. Like 

    it or leave it.

 

Then I would have to object with as much strength as my poor feeble prose can muster. 

 

B. Why not have design principles?

 

I see a variety of risks. I could make this a very lengthy argument with many different objections. But it seems that the longer arguments become, in this working group, the more fragmented the response-threads become. And imagining a socio-historical perspective which might try to reconstruct our decision processes, this would prove expensive to future historians. Is refutation of 28 points any more compelling than refutation of 8 points? Probably not, so let me limit the number of my arguments here to one.

 

Everyone who signed up for the WG was asked to review the group's charter. Each individual and corporation, at that point in time knew (or at least had opportunity to know) what he, she or it was signing up for. If after her acknowledgement of the charter, there comes a change of rules that requires adherence to some new belief system, then what should be the fate of those who, for whatever reason, cannot so believe? 

 

Will such individuals have any recourse but to emigrate to a new and safer haven where such "tyranny of the majority" (real or perceived) is less? If they do elect to stay, then must they live in anticipation that at some point in time some principle they fundamentally disagree with will be used to discard some proposal that they view as crucial to the future of the web? 

 

In situations like this, the minority is often tempted to draft responses like "Congress shall pass no law which ..." followed soon thereafter with language concerning "inalienable rights", "speech" and "religion". 

 

Example: 

 

    B1. The WG shall pass no design principle which inhibits the web's 

    extensibility. (modeled after [13])

 

One may note that a few instances of such language have begun to emerge in recent discussions of fundamental value systems (e.g., [14]). Does the majority really wish to exclude those members who do not believe in the majority's fundamental truths? I hope not. We would then have to call it the "majority wide web". (It does have sort of a nice ring to it though and I do keep imagining some very funny bumper stickers, for those who like slogans. But think of all the textbooks that would have to go into new editions.) The very documents that the PDPs' creators are promoting as well as some of the principles themselves are, I think, highly inclusive, idealistic, and at some basic, level non-tyrannical.  So not only do I hope not, but I believe not. It may simply be that a sense of despair about the possibility of consensus on these issues has emerged. But I think that is the hard business of finding consensus referred to in the teleconference [9]. Let us not assume we have consensus until we explore it; and let us not assume we have no consensus until we first attempt to achieve it. Anything less would be wussy (a technical term).

 

Well, there is encouragement. The chairs (consistent with [8]) have lent a guiding hand and the PDPs have begun to soften to better reflect the contours of a different populace than the body it was originally tailored to fit. That is good, both in terms of cultivating an atmosphere of trust, and in being responsive to what is being said. I think all of us who might have problems with any of the PDPs can feel encouraged that input will indeed be weighed, and not only by PDPs' staunchest advocates, but by others not so engaged in this particular discussion. 

 

C. What cautions should one take with regard to design principles?

 

A part of what has concerned me, and at least some others, about the PDPs, is that they may be over-extended and misused in ways that suppress dissent and inhibit open dialogue. 

 

A cautionary remark, however, already exists within the statement of the principles: 

 

    They are pragmatic rules of thumb that must be balanced against each other,  

    not absolutes.

 

That has been patiently re-iterated at least once and probably oftener [10]. One might imagine that the idealists who draft such proposals will be surprised that anyone might fear bad side-effects from such noble intentions. WHATWG has had years of working together to adapt to its own rhythms and personalities, the PDPs have probably emerged from that social environment and have worked within the spirit of what the group set out to accomplish. But if someone else fears bad side-effects in a new context, it does not mean that one doubts the nobility of your intentions. Yet, despite the cautionary language, and the noble motives behind them, nervousness about the principles has persisted.

 

Perhaps it is that the cautionary remark above is not strong enough. In the extreme we might list a series of examples of how the principles are not to be used. I submit that my straw-man application of one of those principles in [15] is an example of just how these principles are not meant to be used. Certainly that example has many things worthy of arguing about - the arguments are, though, I hope, just quibbles, relative to the magnitude of what is supposed to qualify as fundamental consensual principles. I could have replied to the quibbles. But it would be to no avail. We would just have potentially endless filibusters concerning quibble-laden threads unraveling to the satisfaction of none and the persuasion of few. It is that sort of zealotry we wish to guard against, and as much as one might argue that no one would ever be so zealous, then why don't we make sure that such zealotry is curtailed before it begins?

 

Strong medicine, like strong design principles, often needs to be accompanied by strong warning labels to guide against misuse.

 

Example Disclaimers (to accompany the PDPs):

 

    C1. In no case shall these principles be used as the sole justification for 

    dismissing a serious proposal of an HTML feature made by a working group 

    member. Proposals of features should be judged on their own merits; where 

    appropriate, design principles should be used as reminders of what, by 

    consensus, we have agreed we are working toward. 

 

    C2. These principles are non-normative.

 

    C3. None of the principles herein should be construed as inhibiting the 

    extensibility of the web.

 

C1 is a bit strong. C2 is a bit terse and though it seems to carry meaning within the W3C, I'm not sure I understand it.

 

If C3 were included, though, then I might well be persuaded to drop my objection to "don't reinvent the wheel."

 

As I mentioned some time back, I still have a few quibbles here and there, with some of the others, but nothing that makes me think consensus will remain forever elusive.

 

Respectfully,

David

 

[1] http://lists.w3.org/Archives/Public/public-html/2007JanMar/0804.html

[2] http://lists.w3.org/Archives/Public/public-html/2007Apr/0679.html

[3] http://lists.w3.org/Archives/Public/public-html/2007Apr/1109.html

[4] http://lists.w3.org/Archives/Public/public-html/2007Apr/1552.html

[5] http://lists.w3.org/Archives/Public/public-html/2007Apr/1598.html

[6] http://lists.w3.org/Archives/Public/public-html/2007Apr/1154.html

[7] http://lists.w3.org/Archives/Public/public-html/2007Apr/1164.html

[8] http://lists.w3.org/Archives/Public/public-html/2007Apr/1210.html

[9] http://www.w3.org/2007/04/26-html-wg-minutes

[10] http://lists.w3.org/Archives/Public/public-html/2007Apr/1161.html

[11] http://esw.w3.org/topic/HTML/ProposedDesignPrinciples

[12] http://lists.w3.org/Archives/Public/public-html/2007Apr/0017.html

[13] http://lists.w3.org/Archives/Public/public-html/2007Apr/1528.html

[14] http://lists.w3.org/Archives/Public/public-html/2007Apr/1621.html

[15] http://lists.w3.org/Archives/Public/public-html/2007Apr/1532.html

 
Received on Sunday, 29 April 2007 02:18:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:43 UTC