Re: About the Web Forms 2 proposal

Hi Maciej,

We really do need to get past this declarative versus imperative debate 
because in no way does XForms impose on a form author to use strictly 
declarative expressions, nor even does it impose on a form author to use 
declarative expressions at all.

XForms not only has a well defined imperative mechanism whose "scripts" 
can be invoked by events, but it also includes hooks that allow 
*javascript* to manipulate the XForms data.

The declarative expressions are intended to make calculation of values and 
certain key properties easier to maintain, but the form author is welcome 
not to use them if he feels uncomfortable with the concept.  Yet, the 
second killer app of computing is the spreadsheet precisely because it 
transferred computing power from the computing specialist to the domain 
specialist, so there is plenty of precedent to suggest that declarative 
expressions are in fact of significant value in real situations.

Even in a toy form, it is easy to see where the benefit lies.  Say I have 
a form that takes two inputs and shows their sum or product.  The author 
can write one formula that is always imposed, or he can write two value 
change event handlers, one on each input control, to recompute the result. 
 As the complexity of the computing requirements increase, the benefits 
become more pronounced.  Bottom line, when something is a business rule, 
then express it as a rule not as a block of script attached to event 
handlers for all the places that the rule could possibly cause a change 
for the end-user.

But when something isn't a rule, then don't try to jam it into a 
declarative construct.

The power of XForms is not that it is a declarative system, but rather 
that it *has* a declarative system.  In other words, the power in XForms 
comes from the fact that it is a *hybrid* system in which imperative 
script commands are each empowered and tailored to a particular business 
function by the declarative constructs that are also present within a 
document.

It is easy to see this in action with a simple example, the ubiquitous 
"shopping cart".  Every item in the cart is represented by row of UI 
controls to allow the user to express the thing they want to buy, and the 
cost of each of those things is represented in that row as well. 
Cummulative results like the subtotal, taxes and grand total must also be 
calculated.  Now suppose a user wants to delete an item.  In XForms you 
could just say one command to delete the data element representing the 
shopping cart item because the declarative constructs will then 
automatically remove the UI controls for presenting the data and adjust 
the cumulative results since a deleted item no longer contributes to the 
subtotal, tax and total.

Or you could write script (either Javascript or otherwise) to perform all 
of these steps manually rather than having sensible things done 
automatically for you.  So you could write the script to delete the UI 
controls even though it is obvious they should go because the data they 
represent has been deleted, and you could write the script to recalculate 
the subtotal, tax and total even though it is obvious they should be 
recalculated because some data relevant to their results has been deleted.

In any case, it should be clear that you *can* do all of this with script 
(javascript or the data manipulation actions of XForms).  It's just that 
it's easier to express and maintain with a hybrid approach in which script 
does what script is good at and declarative constructs are there to make 
the script commands more meaningful and powerful.

And again, when you escalate from small examples like a shopping cart to 
the full breadth and depth of what people are increasingly trying to do on 
the web, the benefits of the hybrid approach become ever more pronounced.

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





Maciej Stachowiak <mjs@apple.com> 
Sent by: public-html-request@w3.org
04/28/2007 06:14 AM

To
Sebastian Schnitzenbaumer <sebastian@dreamlab.net>
cc
Dave Raggett <dsr@w3.org>, Matthew Raymond <mattraymond@earthlink.net>, 
public-html@w3.org
Subject
Re: About the Web Forms 2 proposal








Hi Sebastian,

On Apr 28, 2007, at 5:22 AM, Sebastian Schnitzenbaumer wrote:

> Maciej Stachowiak schrieb:
>> In conclusion, based on my experience working with web developers 
>> at Apple and elsewhere, I see no evidence of your claim that 
>> delcarative features are important to website owners. I will admit 
>> I could just be talking to the wrong website owners, but I have 
>> talked to the ones you cited specifically.
> I think this is the heart of the debate, and I am somewhat glad we 
> are getting to this point.
>
> Obviously, we disagree. XML would be a failure if declarative 
> features would not be important to website owners.

I think it's overly harsh to call XML a failure. While its true that 
quite a bit less than 1% of resources on the public web are in XML 
formats, XML still has many valuable niche uses.

> Regardless of whether we agree or not, please recall that a certain 
> amount of W3C members consider the endless co-existence of an 
> imperative HTML world together with a declarative XML world as 
> suboptimal and would like to see a them grow together over time.

HTML is no more inherently imperative than XML. JavaScript is 
imperative, and can be used with HTML and many XML technologies. 
XHTML, SVG, XPath and XSLT are among the more popular ones to use 
with JavaScript, besides just plain XML. Is that the kind of thing 
you have in mind?

> This is what Dave, myself and others are trying to do. OTOH, Ian, 
> Anne, yourself and others do not see them growing together over 
> time as a goal, and are fine for HTML5 and subsequent versions to 
> diverge from the rest of the more declarative XML stack of the W3C 
> forever.

My goals personally, and Apple's goals, are for useful technologies 
to function well, be improved on their own merits, and work together 
when combined. I don't know how "grow together" or "diverge" play 
into this. If "grow together" means that technologies with extremely 
wide adoption should be changed to be more like ones with far less 
adoption, then I guess I'm not in favor of it.

More generally, I think declarative features are useful for capturing 
the common cases of behavior. They can often make simple things easy. 
Regrettably, they also often make complex things impossible or 
extremely difficult. So scripting is still needed. When augmenting 
scripting APIs with declarative markup for the common cases, it's 
important to think about how wide a range of uses you can cover 
without making things harder than scripting would have been. It's 
never going to be 100%, but if you can hit 80%, you are doing pretty 
well.

To get back to the specific example of forms, a lot of forms today 
don't use any scripting. Some use quite fancy scripting which is 
unlikely to be replaceable by anything declarative. I'd like to see 
some info on how large the category in between is, the category of 
forms that do use script but could be reasonably redone without it 
with expression language features. My gut feeling is that it's not 
that big - the forms that do use scripting tend to be very concerned 
with exact details of the user experience. But I'm willing to be 
proven wrong.

Regards,
Maciej