Subject: Re: forms-lite testbed - msg#00032

Hi Dave,

(The following are my personal views.)

This is very interesting stuff. I would like to make some general
comments about the context though, since I think YAFP (yet another
forms proposal) is not really what is needed at the moment.


THE XFORMS ARCHITECTURE

The key thing, I think, is that we don't want a false separation of
XForms 'and the rest'. In particular, phrases like "easier to work
with than the XForms syntax" are very misleading. :) I'm not saying
that they are _intentionally_ misleading, only that the distinction is
unnecessary, and we're certainly on the wrong track if we're already
saying that 'forms-lite' can be 'transformed into XForms at some later
date'--that does not help authors to 'future-proof' their forms.

Admittedly, the XForms WG has been slow off the mark in making sure
that XForms is actually HForms++, but the argument that it's necessary
to do that is now largely won within the group, and some exciting work
is going on to ensure that there is a simple route that goes from
HForms, via the addition of simple features, until eventually you get
to XForms.

So, I believe that the way to square the circle is to say that HForms
*is* XForms, in all but mark-up--giving authors a guarantee that they
can add more powerful features as they go.

In other words, even if you don't use a single XForms element in an
HTML form, you still conceptually have things like a model,
master-dependency graph, validation engine, and so on, 'behind the
scenes'. Of course, in a traditional HTML form, running inside a
traditional HTML browser, you don't _really_ have a dependency graph;
but it's important to act as if you do, since it means that we then
have a consistent architecture across the board, and we can work out
what syntax is necessary to provide authors with a smooth upgrade path
without having to transform--or lose--their forms in the future.

I think building on the architecture is crucial, since one of the key
ideas of XForms is that it takes an MVC approach, and this is the big
leap that it makes beyond HForms. To reduce the differences to a
'battle of syntax' between XForms and WF 2.0 (and now forms-lite!), is
therefore to miss the point about XForms' true revolution.
Significantly, by providing an MVC architecture, XForms provides all
of the concepts needed to carry out all of the requirements emenating
from the Ajax-world, with the added bonus that when people need ever
more powerful features, XForms has them ready and waiting.

I know that you know much of this Dave, and that some of these XForms
ideas actually originate with you! I'm going over this ground merely
to flag up explicitly that we don't need a new forms *architecture*,
since XForms gives us that; what we do need though, is some additions
to the syntax to make it easy for people using HForms to add more and
more of the features from XForms.


AN HFORM IS AN XFORM

In what way, then, is an HTML form, simultaneously an XForm?

Let's take a simple HForm, like this:

<form method="get" action="http://example.org>
<input name="A" value="3"/>
<input name="B" value="4"/>
</form>

This is trivially expressed in terms of the XForms architecture, so I
won't bother going into it.

But moving on to something like summing these two values, we would
need some help from the XForms architecture (the syntax is not final,
and is only my own working hypothesis, but I think it gets the idea
across):

<form method="get" action="http://example.org>
<input name="A" value="3"/>
<input name="B" value="4"/>
<output value="$A + $B"/>
</form>

All we're doing is allowing the XForms output element to be used,
without needing to explicitly add an XForms model element. That's
something that is already in the XForms spec anyway, so we haven't
exactly pushed any boundaries! But in the past the Working Group
tended not to promote these kinds of techniques (ones that made it
easier for authors!), preferring to focus instead on schema validation
and complex bind statements. ;)

But I want to emphasise even with this one additional element, the MVC
model and the dependency-engine sits behind this, making it far easier
to use than WF 2.0's copy of the XForms output element, which is still
rooted in the procedural approach, and doesn't even use the idea of
'refresh' phase, which many Ajax libraries are now doing, as
illustrated by the following example from the WF 2.0 spec:

<form>
<p>
<input name="a" type="number" step="any" value="0"> *
<input name="b" type="number" step="any" value="0"> =
<output name="result" onforminput="value = a.value * b.value">0</output>
</p>
</form>

Anyway, continuing with the idea of small steps that reveal more and
more of the XForms architecture--although I want to emphasise again
that the actual way of marking these things up has not been finalised
by the XForms Working Group--we could make a control into an XForms
range control, like this:

<form method="get" action="http://example.org>
<input name="A" type="range" value="3"/>
<input name="B" value="4"/>
<output value="$A + $B"/>
</form>

Of course that's pretty obvious, and is what everyone is proposing,
but the difference here is that if the XForms WG agrees to add to the
XForms specification the ability to specify controls in either of
these two ways:

<range ... >

<input type="range" ...>

then we haven't broken with the XForms architecture when we use the
HForms-like syntax. And that means that if you suddenly find that you
need to make use of more advanced XForms features like SOAP requests,
schema validation, the chaining of four submissions together one after
the other, registering for the invalid or change events, using
incremental control updates, and so on...well, you can. It's all there
waiting for you, because the syntax you are using is just one of many
possible representations of the *full* XForms architecture--one that
just so happens to 'look like' HTML.

By using this approach you get to future-proof your forms, because you
are no longer making a switch from HTML forms, WF 2, or forms-lite
when you need advanced features...you're already using XForms.

For one final example, I'll use @required. Let's say that in XForms we
allow the @required attribute to appear on form controls:

<form method="get" action="http://example.org>
<input name="A" value="3"/>
<input name="B" value="4" required="$A = 7"/>
<output value="$A + $B"/>
</form>

I know that this is exactly what you have done Dave; but the
difference here is that I've defined it in terms of an alternate way
of expressing the 'one and only' XForms architecture and my 'required'
attribute (the one from XForms) brings with it 'for free' the *already
defined* "xforms-required" and "xforms-optional" events, the required
and optional pseudo-classes, and so on.

(You might ask why attributes like this wern't allowed on controls in
the first place in XForms, and in my view there is a very good
explanation; in the early days of XForms it was quite a big deal to
try to recast forms mark-up using an MVC model, since HTML forms are
so far removed from such a design. But MVC is now so central to XForms
that it is not going anywhere, and I think we are now in a position to
'lighten up' a little, and not be too resistant to allowing some form
features to operate only in the view.)


CONCLUSION

My main argument here is that of all the forms proposals on the table,
XForms is the only one that has defined an entire architecture, with a
clear processing model, that is built on standards, and that can scale
to incredibly complex forms. It's this architecture that we want to
leverage, and to this end the XForms Working Group is putting
resources into ensuring that it is possible for HTML and Ajax authors
to 'be part' of this architecture, and so 'future proof' their forms.
In my view, this work would benefit enormously from what you are
doing, but I don't see the need for a 'forms-lite' project that is
distinct from XForms.

All the best,

Mark

--
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@xxxxxxxxxx
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/

As promised, I have been working on a series of experiments on
incremental extensions to HTML forms with a view to stimulating
thinking about potential stepping stones to full blown use of
XForms. You can explore my work at:

http://people.w3.org/~dsr/forms-lite/

This involves experimental proposals for several new attributes
for the HTML input and fieldset elements, and is designed to
reduce the need for client-side scripting for web-page forms,
whilst being a easier to work with than the XForms syntax. It
should be straightforward to transform into the XForms markup
when needed. This work reuses attribute names proposed for
WebForms 2.0 and XForms where practical.

The examples use a JavaScript library to interpret the additional
attributes and seems to work on IE, Firefox and Opera, but see
the caveats at the end of this email. The library has yet to see
extensive testing so be gentle and please report any problems you
find. I hope to add support for using Ajax to load and save forms
as XML, and to export the markup for the XForms data model.
The library can be deployed as a 6 Kbytes gzipped file and as
such isn't onerous on desktop browsers. It is released as freeware
under the terms of W3C's software license.

Here is a summary of the new attributes and what they do:

calculate
This is used with the input element for spreadsheet like
formulae for calculated fields, e.g. calculate="x+y" where x
and y are names of other form fields. The forms-lite library
takes care of the dependencies between calculated fields using
a topological sort.

pattern
This is used with the input element to constrain input to
match a regular expression.

additional values for the input type (or datatype) attribute
In particular, number and date. For dates, the value entered
by the user is converted into a standard form, e.g. 11 oct 2006
becomes "Wed, 11 Oct 2006". In principle the date type could
be used with a browser provided date picker.

min and max attributes
These are both used on the input element in conjunction with
the number or date types, and constrain the value to be
between the min and max values supplied with these attributes.

range and step
When the type attribute on the input element is set to
"range", the user interface changes to allow the user to
select a value between min and max, at increments defined
by the step attribute. The library can be customized to alter
the user interface associated with the range control.

validate
The validate attribute is used with the input element to
supply an expression over form fields that evaluates to
true or false, e.g. <input name="y" type="number"
validate="y &gt; x"/> which says that this field value
must be greater than the value of the field named "x".

required (or needed)
This is an expression like validate but requires the user
to have filled out a value for the field. The library
evaluates expressions by first rewriting them and then
calling the JavaScript eval function.

relevant
This may be used on HTML input and fieldset elements to
indicate when the associated group of fields is relevant.
It is an expression similar to validate. The library
dynamically adds or removes class values so that the style
sheet can be used to hide the fields when they are shown
to be irrelevant. Such fields are not included when the
form is submitted.

repeat
This attribute is used on the fieldset element when the
associated controls form part of a repeating group, e.g.
as in a sequence of line items in a purchase order.

It so happens that Opera 9 has implemented WebForms 2.0 in such a
way that causes problems for using the required and type attributes.
My work around is to also support the use of "datatype" as a synonym
for "type", and "needed" for "required".

I have dynamically added and removed class values to reflect the
current state of form fields. In principle, this could be replaced
by the pseudo classes defined by the CSS3 Basic User Interface
module, e.g. :invalid and :read-only, although these would need
a native implementation to support them. See:

http://www.w3.org/TR/css3-ui/

I would also like to see CSS support for determining which
user interface control is used e.g. a slider with a numeric
display or a text box with spin up/down for range controls,

In closing, note that this is experimental work and hasn't been
subject to the rigorous testing needed for commercial products.
My aim is to continue to improve the library as I become aware of
problems. If you are interested in helping with testing and further
development please let me know.

Dave Raggett <dsr@xxxxxx> W3C lead for multimodal interaction
http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)