Re: A forms-lite straw man

XForms 1.1 is Turing complete.

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

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





Henri Sivonen <hsivonen@iki.fi> 
Sent by: public-appformats-request@w3.org
09/06/2006 04:29 AM

To
Dave Raggett <dsr@w3.org>
cc
Lachlan Hunt <lachlan.hunt@lachy.id.au>, www-forms@w3.org, 
public-appformats@w3.org
Subject
Re: A forms-lite straw man







On Sep 6, 2006, at 01:27, Dave Raggett wrote:

> On Tue, 5 Sep 2006, Henri Sivonen wrote:
>
>> It is possible and even convenient to use JavaScript closures 
>> attached to the DOM nodes of form fields for binding the form 
>> fields with an XHR-load/saved data model document tree. Such an 
>> arrangement has the benefit that it is backwards-compatible with 
>> existing Web browsers (including IE6).
>
> But why go to such difficulties when a declarative solution is
> achievable?

I didn't find it a difficulty, and it worked with the existing 
browsers that I was required to support. Indeed also for someone else 
doing similar things, compatibility with notable existing browsers 
would likely be an important consideration.

> A cross platform JavaScript libarary can provide
> support for existing browsers, enabling authors to focus on
> declarative markup rather than scripting.

A few lines of JavaScript closure creation on top of existing 
interoperable browser features is a simpler solution than including a 
JavaScript-based interpreter for a declarative language.

> Also from what I hear,
> many developers are having trouble with Ajax and XHR.

That's only anecdotal evidence and even if it were representative, it 
wouldn't follow that the same people wouldn't be having trouble if 
they were using XPath or XForms instead.

>>> If the expression evaluates to false, the field is considered to 
>>> be invalid. I got the name wrong and it should have been called 
>>> validate. The expression could act over just the field's value, 
>>> but it could also refer to the values of other fields. It could 
>>> even call out to a function defined as part of a web page script.
>>
>> What is the advantage over calling a JavaScript function from the 
>> onchange handler? http://whatwg.org/specs/web-forms/current-work/ 
>> #setcustomvalidity
>
> If you are good at maintaining custom JavaScript, then perhaps the
> benefit is less valuable to you, but a simple expression will be
> easier to check for others.

If indeed a simple expression is enough, it could be a single 
JavaScript expression wrapped in a this.setCustomValidity() statement.

I fail to see how having more programming arsenal than mere 
expressions available to the developer would cause difficulty or 
hardship for the developer. I do understand that one cannot do the 
kind of static analyses on arbitrary JavaScript that one could do on 
purely functional programs. However, I value the things that 
JavaScript allows me to do today more than I value the potential 
future benefits that the ability of user agents to statically analyze 
expressions might provide.

> Sure, a Turing complete procedural solution is indeed very powerful,
> but that's the point. A more constrained approach is easier to
> verify against the application requirements.

It seems to me that verification methods for computer programs have 
not--over the many years the subject matter has been researched-- 
reached a level of practicality where one could apply verification 
methods to non-trivial code without an undue effort or undue 
restrictions on the programming paradigm or methodology. Moreover, 
formal verification of software against requirements only moves to 
human error to another stage: the stage of formally expressing the 
requirements.

> I guess I won't be able to convince you of the
> benefits of declarative representations.

I quite like Turing-complete imperative languages for developing 
applications. :-)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/