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

Hi Matt,

> WF2:
> | <label>First name: <input name="firstname"></label>
> | <label>Surname: <input name="surname"></label>
> |
> | <output onforminput=
> | "value='Hello, ' + firstname.value + ' ' + surname.value" />
>    It's not quite a simple as your above example, but it's pretty close.

I agree it's quite simple, but the fact that you say that XForms is
even simpler is an incredibly important point.

The argument for Web Forms 2.0 is usually that XForms is too complex,
and that authors need something that's just a bit more powerful than
HTML forms, but not too powerful. I have two problems with that
argument. The first is that authors will quickly come up against the
limitations of WF2 and then need something else, so it's a false
economy to create just a simple language. That's why Ajax libraries
are proliferating, and becoming increasingly popular. The second
problem I have with this view is that it is incorrect that XForms is
too complex for the simple task, which means that authors looking to
move beyond HTML forms would be best off starting with XForms, and
learning more advanced techniques as they need them.

At the moment that's not completely possible, because there are some
quirks in XForms that mean that some simple things aren't quite simple
enough. But if we can iron those few examples out, we will have a
unified language that suits both simple use-cases and more advanced

> XForms Transitional:
> | <label>First name: <input name="firstname"></label>
> | <label>Surname: <input name="surname"></label>
> |
> | <input readonly calculate="'Hello, ' + firstname + ' ' + surname">
>    See that XForms Transitional is even simpler. When we hybridize the
> two, we get something that's conceptually identical to your example:
> WF2/XFT hybrid:
> | <label>First name: <input name="firstname"></label>
> | <label>Surname: <input name="surname"></label>
> |
> | <output calculate="'Hello, ' + firstname + ' ' + surname" />

I'm not sure it's 'simpler' at all. Why should a label contain the
control? That seems upside down to me. And why does an output control
have a calculation property? That doesn't seem very MVC; we should
either say what the value of the output is (which might in turn be the
result of a calculation), or we should say that some new value in the
model is created via a calculation, and the output refers to that.

But anyway, putting that aside--since to some extent, issues like this
will be a matter of taste--the big loss by using your example
(WF2/XFT) is that you are no longer dealing with XForms, and you now
have three form languages:

  * HTML for the past;
  * WF2/XFT for the so-called easy stuff;
  * XForms for the easy stuff and the complex stuff.

My argument is that the justification for a third approach that copes
with 'simple' examples is unnecessary, since XForms can already cope
with those simple use-cases. And not only does it cope with the 'easy
stuff', it has the advantage that it has a whole array of more complex
features available as the author begins to demand ever more



  Mark Birbeck, formsPlayer | +44 (0) 20 7689 9232 |

  standards. innovation.

Received on Monday, 30 April 2007 12:14:15 UTC