Re: Mostly Harmless or Warning Label Required? [was RE: Review of Proposed Design Principles]

Hi David,

Just so we're clear, the bit I wrote about "why bother with creating 
language to express 'C = A+B' when we already have 'insert assembly code 
here'"? was a rhetorical question in response to other people. 

One person asked why they should bother adding XForms-based features like 
declarative expressions when there were already imperative ways of doing 
things. 

Another said that big problems could be broken down into small problems, 
so solving the small problems will get you to the big problems.

That's like inventing an octagon-shaped wheel.  Yes, you'll get there 
one-eighth at a time, but you just won't get that rolling coefficient of 
friction unless you go through the method of exhaustion and invent a wheel 
that is round!

So I absolutely don't ascribe to principles like "Don't invent another way 
to say X" because there might be some very handy other ways to say X that 
are not so tedious as the machine language of the web that we have today. 
And then, there might be other things besides X that become much easier to 
say that we don't find occurring on the web very often *because* they are 
currently too hard to say.

And I don't subscribe to the notion of choosing features based on whether 
or not they will be too hard on the web browser makers.  We have a choice 
here.  Make it easier on the millions of people who have to author and 
maintain documents or make it easier on a few browser vendors now.  The 
document author is where our responsibilities lie. 

Moreover, back in 2001 in the XForms group, many a member screamed aloud 
how impossible it was going to be to create an automatic system of 
resolving declarative expressions.  I couldn't believe what I was hearing, 
so I wrote the spec in the two days following that telecon in order to 
show how easy it would be.  When we got to the next telecon, the wailing 
started anew... until the developer of one of the XForms implementations 
muted all opposition by saying simply that he had implemented my spec in 
the few days remaining before the telecon.

So, in the span of one week, the XForms working group went from objection 
to completed implementation.

This is why the ongoing objections have me mystified.  It would take far 
less effort to up and do the work than it would to continue a debate that 
was resolved 6 years ago. 

John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





"Dailey, David P." <david.dailey@sru.edu> 
Sent by: public-html-request@w3.org
05/01/2007 05:58 PM

To
"Doug Schepers" <doug.schepers@vectoreal.com>, <public-html@w3.org>
cc

Subject
Mostly Harmless or Warning Label Required? [was RE: Review of Proposed 
Design Principles]







On Tue 5/1/2007 4:16 PM Doug Schepers wrote

>I've reviewed "HTML Design Principles (Proposed)", and I approve of all
>but one of the principals.  Again, I don't think any of them should be
>sacred and inviolate, but they seem mostly harmless.

To my knowledge no one has yet objected to my proposal 
http://lists.w3.org/Archives/Public/public-html/2007Apr/1667.html to add 
additional caution into the language framing the design principals. I had 
suggested three differing levels of caution.  Would anyone object to 
adding my favorite? 
 
C3 "None of the principles herein should be construed as inhibiting the 
extensibility of the web."
 
These principles are "Mostly harmless" are they? (Well I still am not sure 
I am convinced of what goodness they add, but maybe I'll begin to see that 
once I have a sense that there really is consensus and not a rush to 
judgment --[2] [6]; but I did like that book by your namesake Doug  so I'm 
willing to be persuaded simply through your nonchalance alone [0],.)
 
That such principles can be used in ways contrary to the objectives of the 
group seems quite possible.
 I believe that no guideline should be used without additional supporting 
logic.[1]
 
In the case of 
http://lists.w3.org/Archives/Public/public-html/2007Apr/0376.html  a 
suggestion was made and purportedly "refuted" by reference to one of the 
not-yet-agreed upon and previously un-explained principle. The suggestion 
was later "refuted" by an argument I liked better ("use script not markup 
for this since would be hard on the browser makers") so I let the issue 
drop. However  the interpretation of "degrade gracefully" as used in this 
context remains still elusive to me on grounds expressed in 
http://lists.w3.org/Archives/Public/public-html/2007Apr/0679.html . To me 
the above example does not degrade ungracefully, it just looks like text 
rather than a table which is exactly what an author would expect. 
Therefore I think additional caution may be needed as well as a few more 
examples to shore up the meaning of "degrade gracefully."[4]
 
I have seen others raise arguments that would seem to take issue with 
"don't reinvent the wheel." I cannot speak for them to say for sure if 
their comments would lead them in that direction or not, and they can 
either verify or deny that their statements lend support to my argument 
but
 
John Boyer in 
http://lists.w3.org/Archives/Public/public-html/2007Apr/1760.html wrote:
 
-----------
Why would we ever write a language that allows one to say C = A + B; 
when we already have
LOAD AX, 1000
LOAD BX, 1004
ADD AX, BX
STO AX, 1008
???
--------------
 
 and 
T.V. Raman in 
http://lists.w3.org/Archives/Public/public-html/2007Apr/1528.html wrote:
-----------------
I think the Web as we know it would be a far poorer place if the
only technologies considered implementable were those bundled in
browsers ---
this would in principle limit all innovation on the web to  one
or a small number of browsers.
The Web has succeeded because it's extensible -- dont break  it!
-----------------
 
I have made several arguments against inclusion of the this principle. How 
about renaming the thing to
"Don't reinvent the wheel unless there is a better wheel, or the current 
one is broken"? [3], [5]
 
In the worst case I think Design Principles can foment disagreement more 
than forestall it particularly when they are used as a magic wand to make 
an unpleasant suggestion go away. In the worst case, they  need more than 
the existing cautionary language about "not being taken as absolutes;" 
they need warning labels.
 
The misuse of a design principle (through either zealotry [7] or simple 
misunderstanding) can serve to aggravate a discussion which began as a 
logical one by adding a moral dimension which did not already exist. I 
believe a future dissection of the corpus of this WG's discussion will 
prove my point -- but that is an empirical question for which I do not 
think anyone is suggesting we take the time now to do.
 
Like Doug, I share optimism that convergence is in sight, but there 
remain, I think, some of what TBL calls "hairy" issues remaining..
 
If everybody's ready to tack on C3 above to the design principles, then I 
think we're getting close. Get #1 straightened out (though this could be 
tough since there are some real differences of opinion being expressed 
here); add some more clarification to #2; maybe change the Wheel one; add 
some possible examples of how not to use design principles, and add a firm 
boundary on their application (rather like a bill of rights like C3) and 
then I'm as happy as I suppose one so skeptical of aphorisms can be.
 
David
 
>From Alphabetic Aphorisms c1986.
[0] An amusing analysis actually alleviates anxiety.
[1] Fanciful feuds follow from familiar foundations.
[2]  Hurrying hastens heartache.
[3] In ignoring imagination, industry is intolerant
[4] Mentioning mistakes may make more misunderstandings.
[5] Overlooking old obstacles often obscures opportunity.
[6] Pompous policies poison potential partnerships.
[7] Zaniness zaps zealotry.
http://srufaculty.sru.edu/david.dailey/words/aphorisms.html