Re: declarative expressons in WF2

As a follow up, someone in the forms working group suggested that it 
would be practical to prohibit custom functions and to instead rely 
on a small set of prefined functions for which the semantics can be 
clearly defined. The use cases I have looked at have only needed 
simple mappings from field values to prices etc. that can easily be 
expressed as associative arrays, e.g. price[productCode].

Some use cases:

  - Ordering pizza where the total price is computed from
    the pizza size and the number of toppigs, and the price
    per topping depends on the pizza size.

  - Application form for a loan where you are asked for details
    of your previous home if you haven't been at your current
    residence for more the 3 years.

  - Wizard for ordering a custom desktop PC online, where the
    wizard takes you through a series of choices and shows you
    the running total and a summary of the specification so far.

  - Employee expense claim form used as part of a workflow
    process that is signed off and then paid. This form involves
    intercolumn calculations in a repeated data set.

  - Tax form with lots of sections that are revealed as appropriate
    according to how you have filled out earlier sections

All of the above can be represented in a declarative way without the 
need to resort to scripting. The ability to hide section of the form 
until needed makes the process of filling it out less intimidating. 
Simple expressions make it easy to define the conditions under which 
different sections of markup are relevant and should now be shown.

  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

On Sun, 25 Mar 2007, Dave Raggett wrote:

> On Sun, 25 Mar 2007, Anne van Kesteren wrote:
>
>> On Sun, 25 Mar 2007 20:17:54 +0200, Dave Raggett <dsr@w3.org> wrote:
>>> I have introduced a grammar for a subset of ECMA 262 r-value expressions 
>>> together with additional constraints that ensure that the expressions can 
>>> be statically analysed. See:
>>>
>>>   http://www.w3.org/2007/03/XForms-Transitional/#expr-syntax
>>
>>  Note that functions must be side-effect free and avoid
>>  introducing dependencies on form fields other than those
>>  passed via the function's arguments. This is needed to
>>  ensure that the expression can be statically analysed.
>> 
>> Doesn't help an implementor much. It seems you still haven't addressed the 
>> original concern various people expressed either on this mailing list or 
>> #html-wg.
>
> How so?
>
> We all know that it is impractical to analyse turing complete code, and 
> browsers wisely don't try to do so. If your scripts don't behave as you 
> expect, it is generally up to you as the programmer to sort it out.
>
> For the simplest case authors wouldn't need to write functions so that 
> problem wouldn't arise. Any functions that the editor provides would have 
> been written by experts and subject to testing to ensure
> that these functions abide by the rules.
>
> You might say "What's wrong with event handlers?. Everyone in the HTML WG is 
> very comfortable with writing scripts for event handlers, so what's the 
> problem?"
>
> Well we have a duty of care to the rest of the population who don't know and 
> don't care about scripting. If we ignore that duty then the market will make 
> a correction. HTML will be sidelined as a delivery format and won't be an 
> editing format.
>
> In IRC you suggested that editors could recognize the scripts that they 
> generated. That's true, but leads to the undesirable situation where you can 
> only edit a document if it was created by that editor.
> Switching back to a text editor isn't an option for people who don't know 
> about HTML, CSS or JavaScript.
>
> The same problem occurs if the editor saves the semantics for the event 
> handlers in a non-standard declarative format since this will prevent other 
> editors who don't know about that format from being able to offer an 
> effective service to non-technical users.
>
> I think this is a critical question for the HTML working group. I am striving 
> to provide a technically sound solution for extending WF2 with declarative 
> expressions, but if the working group isn't willing to consider this, I would 
> like a decision earlier rather than later.
>
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
>

Received on Monday, 26 March 2007 14:32:12 UTC