RE: A forms-lite straw man

HTML4 checkboxes are present/absent, with a specified value, not a
true/false value, so it would still be xsd:string but required=false.
Also HTML4 submits the same name many times if an input is present
multiple times; many forms use this.  The XForms 1.0 serialization
allows this with an explicit model and instance because the
serialization rules work for identically-named elements, but the
lazy-authoring features of XForms 1.0 don't do it, because that assumes
all references to foo are to the same foo, not to multiple foos.
Leigh.

________________________________

From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of John Boyer
Sent: Tuesday, September 05, 2006 4:14 PM
To: Lachlan Hunt
Cc: Dave Raggett; public-appformats@w3.org; www-forms@w3.org;
www-forms-request@w3.org
Subject: 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/