W3C home > Mailing lists > Public > www-forms@w3.org > October 2006

Re: forms-lite testbed

From: Dave Raggett <dsr@w3.org>
Date: Sat, 21 Oct 2006 11:57:37 +0100 (BST)
To: Mark Birbeck <mark.birbeck@x-port.net>
Cc: www-forms@w3.org
Message-ID: <Pine.LNX.4.64.0610211046510.5221@holly>

Many thanks Mark for responding to my posting. I agree with you
that the architecture in XForms is more important than its syntax.
The stepping stones I have been exploring are about how to make
use of that architecture with only incremental extensions to the
HTML forms syntax, and to do so in a way that can be used today
with existing browsers without the need for plugins.

The experiments are intended to explore opportunities for stepping 
stones between the capabilities provided by HTML4 and those provided 
by XForms. In particular, the means to use simple expressions for 
validating field values and spread-sheet like formulae for computed 
fields, but also the means to describe repeating groups of fields, 
e.g. for line items in a purchase order. All this should be possible 
without the author needing to write any lines of client-side script.

So how to do that?  I chose to stick with the existing HTML4 form, 
fieldset, input, select and button elements, and to consider what 
new attributes could provide the desired behavior. In essence, this 
meant grafting attributes taken from the XForms bind element on to 
the HTML4 input element. Thus type, pattern, validate, required, 
relevant, and calculate. The idea is that the XForms model and 
associated constraints can then be readily generated from the HTML 

The HTML input element already defines a type attribute so it was a 
matter of adding new values, and my experiments looked at doing so 
for number and date. This worked fine on IE and Firefox, but for it 
to work on Opera it proved necessary to use another attribute name 
to work around Opera's implementation of WebForms. I also borrowed 
min, max and step from Web Forms 2.0, for use with an experimental 
range control. Perhaps you can help provide a mapping for the step 
concept into XForms bind constraints? Essentially, the value needs 
to be constrained to be min value plus a multiple of the step, and 
be less than or equal to the max value. I also implemented min and 
max to work with dates, but didn't get as far as implementing min, 
max and mask as facets on strings, but did add support for regular 
expressions with the pattern attribute.

The HTML forms data model in current browsers allows for repeated 
fields with the same name and models these as an array. This made it 
practical to implement repeating nodesets. The HTML fieldset element 
seemed like an obvious choice for a container, and I just added name 
and repeat attributes. The name would map to the nodeName for the 
corresponding container in the XForms model. The repeat attribute is 
presentational and controls the number of rows initially presented 
in the user interface. That raises some interesting questions about 
the back and reload semantics for browsers, but I will leave that 
for a later discussion.

This leaves us with the question of the syntax for the expressions
used with the validate. I chose to stick with a flat space of 
names for fields since this is what is browsers currently support.
XForms 1.0 supports a richer model of data, and when this is needed
that would provide a compelling reason for migrating your web
application to the full XForms syntax. Staying with a flat namespace
for forms-lite therefore seemed like a good compromise, and avoids
getting drawn into the arguments between those who like and those
who don't like XPath. From the point of view of expediency, I used
a technique which meant I could exploit the JavaScript eval 
mechanism to evaluate expressions. This involved rewriting the
expressions when the form was loaded to enable the direct use of

After a detailed study of what it takes to support new elements
in existing browsers, I chose not to implement an output element.
In practice, the input element can be used instead, and can be
set to be read only if needed. This raises a question of how to
allow user entered values to overrride the calculated value for
a given field. This is used, for example, in expense claims to
override the currency exchange rate. The data model needs to
keep track of when an explicit value has been provided. I would
like some help in understanding how this can be expressed with
XForms 1.0/1.1.

  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Saturday, 21 October 2006 10:57:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:18 UTC