Re: forms-lite testbed

For repeat via attributes, I suggest applying the xforms repeat
attributes to fieldset --- we originally designed that set to go
on html tr element.

I understand that there have been some difficulties implementing
this in Firefox due to problems with CSS styling, but modulo that
it should work, and conceptually, html:fieldset can be thought of
as being equivalent to xforms:group.

Further, <repeat>...</repeat>
is conceptually equivalent to <group repeat-attrs>...</group>
modulo styling nits.

Dave Raggett writes:
 > 
 > 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 
 > elements.
 > 
 > 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
 > eval.
 > 
 > 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

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Monday, 23 October 2006 23:56:24 UTC