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

Hi Preston,

Why is it more reasonable to assume that XForms will become a largely 
disused or niche-specific technology?

Why isn't it just as reasonable to assume that XForms-based capabilities 
(in whatever form they ultimately take as a result of collaboration) might 
become some of the most-used capabilities in HTML5?

The only way for this not to happen is for the computing problems we want 
to solve on the web to stop becoming harder over time, for everyone to 
just cool it with this whole demanding more business.  When has that 
happened in the history of the web?!?

It seems you've also hauled out the old bulk-up-the-browser argument 
again.  I refer you to the rest of the email you snipped, which described 
the week back in 2001 where the part we're arguing about was both spec'd 
and implemented.  Heck, it runs on phones for gosh sakes.

And sure, it's clear to me that not everyone will want to use particular 
features.  Regarding any feature, this just isn't news.  You have the same 
issues with HTML features versus CSS features.  In fact, the value of CSS 
relative to certain features of HTML is quite comparable to the discussion 
we are having now about some features in XForms.  Maybe we just shouldn't 
have done CSS because, after all, we already had a way to set fonts and 
colors in HTML, and it would just break the whole web if mixed in a new 
behavior or paradigm... oops, no I guess that nightmare scenario didn't 
actually happen, now did it.

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





"Preston L. Bannister" <preston@bannister.us> 
Sent by: preston.bannister@gmail.com
05/01/2007 10:35 PM

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






On 5/1/07, John Boyer <boyerj@ca.ibm.com> wrote:
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. 


John, 
Assume that other folk have read and understood Brooke's book. 
Assume others have understood and practiced declarative programming. 
Now assume some of those folk may have different opinions than you have 
expressed.

XForms (or something like it) could be implemented as a Javascript 
library, as server-side code, as a browser plug-in, or embedded in the 
standard browser - or as a mix of any of those possibilities.  XForms is a 
domain-specific language (I trust you are familiar with this concept?) and 
as such should prove very suitable for some applications, and less 
suitable for others. 

This leads us to a set of alternatives.
Should XForms implementations be separate from the browser (as at 
present)?
Should HTML standard forms be extended - perhaps to aid XForms 
implementations? 
Should XForms be incorporated into all future browsers?

Seems there are a few different viewpoints on this question. :)

Personally, and am not too fond of the notion of mixing behavior with 
HTML.  Maybe I don't care, since if XForms is incorporated into the 
browser implementations, I do not have to use it.  On the other hand, this 
puts a long-term burden on the browser implementors.  Perhaps in the long 
term XForms becomes a largely disused or niche-specific technology.  In 
that case we are probably better off leaving XForms implementations 
outside the browsers, instead of bulking up the browsers and burdened the 
implementors. 

Seems we need to hash out some sort of consensus on this topic.