Re: About the Web Forms 2 proposal

On Fri, 27 Apr 2007, Matthew Raymond wrote:

> Dave Raggett wrote:
>> On Fri, 27 Apr 2007, Ian Hickson wrote:
>>
>>> On Fri, 27 Apr 2007, Sebastian Schnitzenbaumer wrote:
>>>
>>>> XForms Transitional [...] introduces an expression syntax, Web
>>>> Forms 2.0 does not.
>>>
>>> WF2 doesn't, because it has not been shown how it could work. We 
>>> spent significant time and resources trying to find a way to 
>>> make it work.
>>
>> I think you owe it to the Web to try a little harder as there are
>> many kinds of users, many of which would benefit from such
>> expressions, just like they have benefited from the invention of
>> spreadsheets. Spreadsheets are very widely used and there are plenty
>> of prior art for using expressions for validation and for calculated
>> values.
>
>   I don't think his point is that he'd turn down a proposal on how
> expressions could be implemented in a safe and consistent manner. The
> point is that extensive research and effort have thus far failed to
> solve the problem of expression attributes in HTML.

Please can you summarize the evidence for that extensive research 
and effort, as I can't find it. I am hoping that this isn't just a 
lack of will to thoroughly explore new ideas.

>> A well defined expression language with a fixed set of predefined
>> functions can certainly be made to work. Will you accept the
>> challenge of working out how to make that fit with the rest of WF2?
>
>   If someone wants a feature, shouldn't they be arguing how the feature
> can work rather than challenging others to make it work for them?

I already have and failed to get a meaningful response to the 
proposal for using a well defined expression language with a fixed 
set of predefined functions. I think this is perhaps more a matter 
that other people have yet to realize the potential for lowering the 
development costs for website owners and for enabling high level 
authoring tools for use by people who aren't able to code 
JavaScript. There isn't any fundamental computer science problems to 
solve. Spreadsheets after all are clearly practical and have been 
around for nearly thirty years. I agree that we still need to 
specify the detail of when expressions are evaluated relative to WF2 
event handlers, but that is clearly a matter of detail and not a 
fundamental barrier.

>> It is obviously tempting to identify relevancy with disabled, but
>> that would be to miss an opportunity to support wizards such as you
>> find on online ordering sites (including Apple's) where you are
>> taken through a sequence of choices with material irrelevant to the
>> current state hidden from view. For this we need to be able to
>> hide fields but to do so in such a way that their values are still
>> submitted as part of the form.
>
>   First of all, why would someone conclude that material not 
> relevant would be submitted to the server? That's 
> counterintuitive. Why would you waste bandwidth by submitting data 
> that is irrelevant? It may not be stated explicitly in the XForms 
> Transitional document that |relevant="false"| values are not 
> submitted, but neither does it explicitly state the opposite.

I trust you are open to new ideas. A use case is where say Jon wants 
to buy a computer from examples.com. He goes to the website and uses 
example.com's wizard. This presents him with a series of choices, 
and as it does so, shows a summary of the system so far, but hides 
the questions/input fields for all but the current question as they 
are irrelevant for the purposes of posing the current question. 
Relevancy is thus sensitive to the state of the dialogue.

Here is a concrete instance of this use case, go to the following 
web page and click on iMac:

http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore

This offers the choice of 4 bundles. Pick the 2nd. This takes you to 
a page to customize your Mac. You can now click on radio buttons to 
change various options. The summary shown on the top right changes 
dynamically as you do so.

Now if you look at the page markup you see that it is rather 
complex. It could be made a lot less so quite easily. Let's imagine 
going through an exercise of redesigning the page. We keep the 
summary but present the choices for processor, memory, hard drive, 
modem, applications bundle, keyboard/mouse and warranty, as a 
wizard. In otherwards, first show the choices available for 
processor and hide the rest. The user clicks on a next button to go 
to the next set of choices. This hides the choices for processor and 
reveals the choices for memory, and so on.

This could of course be implemented directly in JavaScript, but that 
is still complicated. We can reduce the need for most of the script 
through declarative techniques. Essentially, add an attribute to 
each section that indicates when the section is relevant to the 
dialogue. A simple numerical or named state will suffice.

The previous/next buttons for the wizard would be represented as 
buttons with the corresponding types (e.g. type="next"). On existing 
or older browsers this would have the effect of submitting the form, 
whereupon the server could do the work of sending an updated page, 
even if scripting is disabled. (note that the Apple page hasn't been 
designed to allow the user to update the summary when scripting is 
disabled).

On new browsers that support the wizard markup, the buttons update 
the wizard dialogue state using the name and value attributes on the 
buttons, i.e. the form's object model is updated to set value on the 
corresponding name. This can then be tested for by the expressions 
given as the value of the relevant attributes on markup for each 
section and also on the summary. The subtotal is express 
declaratively as an expression that sums over the prices for each of 
the choices. This is where we can use a declarative mapping from teh 
choice of say processor to a price. For radio buttons and check 
boxes etc. this could be represented as an attribute on the field, 
and "price" comes to mind as a possible name. However a more general 
solution would be desirable, e.g. for use with text fields. 
JavaScript associative arrays offer one possible solution, or we 
could introduce some new markup for the purpose.

This examples that simple declarative markup can replace a lot of 
costly and hard to maintain script. This might not be of concern to 
browser vendors as they don't bear the cost, but should be of 
concern to website owners who do bear the cost.

Does the HTML WG have any responsibility to website owners? I 
presume (and it is a rhetorical question) that the answer is clearly 
yes!  HTML standards need to satisfy multiple stakeholders and 
not just browsers vendors, althrough they are clearly very 
important.

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

Received on Saturday, 28 April 2007 09:49:58 UTC