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

Re: HTML forms, XForms, Web Forms - which and how much?

From: John Boyer <boyerj@ca.ibm.com>
Date: Tue, 1 May 2007 17:13:03 -0700
To: James Graham <jg307@cam.ac.uk>
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, Dave Raggett <dsr@w3.org>, Maciej Stachowiak <mjs@apple.com>, public-html@w3.org
Message-ID: <OF4F60C1D3.314F6620-ON882572CE.0083559B-882572CF.0001327D@ca.ibm.com>
Hi James,

A point I made already on this list is that XForms blends imperative and 
declarative constructs.
The question is not whether declarative is better than imperative.  As 
your own research has shown,
a blend is better.

The problem is that some folks on this list want proof about why there 
should be *any* declarative
expressions available.  Why not just do everything with script?

In Fred Brookes' book, the Mythical Man Month, research is cited to 
indicate that code
complexity rises at a superlinear rate relative to the number of lines of 
code, on the order
of L^1.5 where L is the number of source lines of code.  This means that 
code which is 10 times
longer is roughly 30 times harder to maintain. 

Although the "Mythical Man Month" is a legendary resource, it is actually 
quite easy to grasp why
reducing code length might have such a dramatic effect on complexity.  If 
you take L commands,
there are in fact L! possible orders for them.  Now, agreed that most are 
"obviously" wrong, and 
some are logically equivalent in that they produce the same result.  Yet 
there are many possible
orders for a sequence of commands that are plausible yet incorrect, even 
if only by a bit.
In a nutshell, the shorter you make L, the less potentiality there is for 
bugs.

In XForms, we use declarative constructs to tailor the meaning of the 
imperative commands that
manipulate the data model and views.  This has the effect of reducing the 
length of scripts, often
to only one or two consecutive commands per event handler. When L is close 
to 1 or 2, it becomes
very hard to pick the wrong order, so you can focus on whether you got the 
parameters right in
each command.

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





James Graham <jg307@cam.ac.uk> 
Sent by: public-html-request@w3.org
05/01/2007 01:48 PM

To
Maciej Stachowiak <mjs@apple.com>
cc
John Boyer/CanWest/IBM@IBMCA, Daniel Glazman 
<daniel.glazman@disruptive-innovations.com>, Dave Raggett <dsr@w3.org>, 
public-html@w3.org, public-html-request@w3.org
Subject
Re: HTML forms, XForms, Web Forms - which and how much?







Maciej Stachowiak wrote:
>> Theorem: Declarative representations reduce bugs
>> Proof: Spreadsheets. QED
> 
> Hmm. Is there any evidence that Excel spreadsheets have fewer bugs than, 

> say, Visual Basic programs of similar complexity? I know of no such 
> evidence. It is certainly possible for spreadsheet formulas to be buggy.

This is rather more the sort of research that I had in mind rather than 
the general statement that spreadsheets are easy to use. Spreadsheets 
are not really a great comparison to HTML since they combine a 
declarative language with a simple but powerful GUI paradigm to 
represent the data -- possibly it is this GUI that affords much of the 
ease of use. The declarative features are also sufficiently limited that 
many large spreadsheets contain significant amounts of imperative code, 
suggesting a tradeoff between ease of use for simple tasks and range of 
applicability. Other declarative languages such as XSLT may make 
different tradeoffs -- I have personally found that, in my limited 
experience with XSLT, the type of tree manipulations I wanted to perform 
were harder (for me) than just writing a script.

Given this, I hope its clear why I was asking about research into the 
general properties of declarative languages to help me understand the 
claims that are being made that declarative languages are a-priori 
easier for authors.

-- 
"Instructions to follow very carefully.
Go to Tesco's.  Go to the coffee aisle.  Look at the instant coffee. 
Notice that Kenco now comes in refil packs.  Admire the tray on the 
shelf.  It's exquiste corrugated boxiness. The way how it didn't get 
crushed on its long journey from the factory. Now pick up a refil bag. 
Admire the antioxidant claim.  Gaze in awe at the environmental claims 
written on the back of the refil bag.  Start stroking it gently, its my 
packaging precious, all mine....  Be thankful that Amy has only given 
you the highlights of the reasons why that bag is so brilliant."
-- ajs
Received on Wednesday, 2 May 2007 00:13:11 UTC

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