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/