Re: A forms-lite straw man

Hi Lachlan,

Sorry, bit of a delay getting back to the point you asked me about...

For easier reading to others, here is a repeat of what Lachlan asked:

>Having said that, though, I may be interested in merging the two in a 
>way that doesn't involve retrofitting the syntax of one into the other. 
>  I'm *still* waiting for John Boyer to explain his intriguing binding 
>idea that he briefly mentioned earlier, which seemed to do just that.


It just seems to me to be easy to say something like:

<input name="Age" type="integer" ... />

is a shorthand for an implied xforms model in which the following appears:

<xf:model>
    <xf:instance xmlns="">
      <data>
         ...
         <Age>40</Age>
         ...
      </data>
   </xf:instance>

   <xf:bind nodeset="Age" type="xsd:integer"/>
</xf:model>

<xf:input ref="Age">
   <xf:label>Age</xf:label>
</xf:input>

I'd have to look at the details, but I wonder whether we can work out an 
easy way to extend this to the scenario where type is used to indicate the 
kind of control, e.g.  a checkbox could imply a node of type xsd:boolean. 
We'd need to check whether the strategy would imply the need for further 
improvement to the XForms submission of www-form-url-encoded data, but I'm 
pretty sure that's an improvement we need anyway... 

Cheers,
John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Lachlan Hunt <lachlan.hunt@lachy.id.au> 
Sent by: www-forms-request@w3.org
09/05/2006 08:36 AM

To
Dave Raggett <dsr@w3.org>
cc
www-forms@w3.org, public-appformats@w3.org
Subject
Re: A forms-lite straw man







Dave Raggett wrote:
> Rising to Mark's challenge, here is a sketch of of a proposal that is 
> both syntactic sugar for a subset of XForms and an incremental 
> improvement on HTML4.

As well as identifying the improvements that should be made, we should 
also examine which issues WF2 currently does and does not address.  I 
think it's quite clear that I'm strongly against needlessly retrofitting 
the XForms or other XML syntax into HTML to meet these requirements.

The functionality is what's really important, not whether or not it uses 
XML syntax.  If people feel that XHTML+XForms+OtherXML is the future, 
that's all fine and I even somewhat agree; but the whole idea of 
transitioning XML through text/html is ludicrous.

In fact, there is significant evidence to show that such a transitional 
methodology has totally and utterly failed to work for transitioning 
from HTML to XHTML; and has only served to increase the tag-soup-mess of 
text/html, rather than clean it up.

Now, I don't want this to turn into another XML-as-text/html-is-wrong 
debate (as far as I'm concerned, that's over).  Instead, I want people 
to recognise that a transition to XML in the future can quite happily 
occur when support for XML languages is more widespread amongst typical 
users and do so *alongside*, rather than directly integrated with, HTML.

I believe that XForms and WF2 can co-exist as separate but related 
technologies which are suited for different environments and/or 
requirements.  I fully recognise the fact that XForms does have a lot of 
nice features, I'm not disputing the benefits of XForms in any way 
whatsoever.

However, having been involved with the development of WF2 for the past 2 
years and many other areas of real-world web development for much 
longer, I also understand the significant benefits of a language that 
meets the needs of today's real-world authors, based on the technologies 
they use everyday (even though it may be technically inferior to the 
much more theoretically pure XForms approach).

Authors should be able to choose WF2 or XForms based on their specific 
requirements.  For many, the limited features and functionality offered 
by WF2 in traditional HTML-style forms will suits their needs perfectly, 
whereas many others may either require or significantly benefit from the 
the XForms approach.

Having said that, though, I may be interested in merging the two in a 
way that doesn't involve retrofitting the syntax of one into the other. 
  I'm *still* waiting for John Boyer to explain his intriguing binding 
idea that he briefly mentioned earlier, which seemed to do just that.

>   type: an enumerated value from a small set as per HTML4
>         with the addition of {integer, number, date}

various dates and times, number, range, email and url are in WF2.
Integer would be equivalent to something like this:

<input type="number" pattern="-?[0-9]+" ... >

>   verify: an XPath expression evaluating to a boolean

I don't understand the purpose of that.

>   pattern: a regular expression constraining the input value

http://www.whatwg.org/specs/web-forms/current-work/#the-pattern

>   min, max and step: numbers acting as constraints with step
>     being used for ranges

Those are available.  The step attribute works for dates, times, numbers
and ranges.  Min and max apply to those as well as file upload controls.

>   required: an XPath expression evaluating to a boolean

WF2 provides a boolean required attribute.

<input ... required="required"> or simply <input ... required>
http://www.whatwg.org/specs/web-forms/current-work/#the-required

I don't understand what benefit the XPath expression would provide.

>   hint, help and alert: corresponding to XForms elements
>             (use HTML4 label element for the label text)

The title attribute can be used to provide a hint.  A help element may
be a useful addition, though it can be provided already using <a
href="#help" rel="help">.  I'm don't about the alert element.

> Output fields have the following attribute
> 
>   value: an XPath expression evaluating to a string

The WF2 output element uses a JavaScript expression to evaluate to a
string.  What benefit does an XPath expression provide, especially when
you consider ease-of-use and the fact that XPath is defined for XML, not
HTML!?  Also, keep in mind that many HTML authors are already
comfortable with JavaScript and comparatively few are familiar with XPath.

-- 
Lachlan Hunt
http://lachy.id.au/