Steven Pemberton, W3C and CWI, Amsterdam
Co-chair, XForms Working Group
Chair, HTML Working Group
The basis of the e-commerce revolution
Several years' experience has shown where there are shortcomings
XForms is a new XML-based markup that addresses many of these shortcomings
Separation of content from presentation
Strong typing: more checking in the client
Reduced scripting through calculations
Structured data with XML submission
Internationalisation
Accessibility
Device independence
Reduced scripting through declarative event handlers
Can be integrated into other markup languages
Anyone who has tried to unravel someone else's HTML form will know how hard it is to do.
In XForms, by putting details of the data in the head of the document and binding to it from controls in the body, the data collected is more obvious, and more reuse is possible.
Binding is done using XPath expressions
<head>
...
<xforms:model>
<xforms:instance>
<age/>
</xforms:instance>
<xforms:submission action="/submit"
method="post" id="sbmt"/>
</xforms:model>
...
</head>
<body>
...
<xforms:input ref="age">
<xforms:label>How old are you?</xforms:label>
</xforms:input>
<xforms:submit submission="sbmt">
<xforms:label>OK</xforms:label>
</xforms:submit>
...
Optional use of Schema datatypes allows client-side checking.
<xf:model>
<xf:instance src="/cgibin/get-values"/>
<xf:schema src="data.xsd"/>
...
</xf:model>
Instance and schema can be inline, or external as here
Types can also be bound using <bind>:
<xf:instance> <name/> </xf:instance> <xf:bind type="nonEmptyString" ref="name"/>
<xforms:model>
<xforms:instance>
<code>123-45673-323</code>
<number/>
<cost>9.99</cost>
<total/>
</xforms:instance>
<xforms:bind readonly="true" ref="code"/>
<xforms:bind readonly="true" ref="cost"/>
<xforms:bind readonly="true" ref="total"/>
<xforms:bind calculate="number*cost"
ref="total"/>
...
</xforms:model>
Collected data can be sent to the server as an XML instance.
<instanceData>
<cc>MC</cc>
<nr>12345678909</nr>
<expires>12/01</expires>
</instanceData>
Legacy submission is also supported
Better support for character encodings.
Purpose-oriented form controls (rather than presentation-oriented ones) allow use on accessible devices ("select1" not "radio", etc.)
<label> element is present on all controls, <hint> and <help> elements are optional.
<f:select1 ref="cc">
<f:label>Credit card</f:label>
<f:item>
<f:label>Mastercard</f:label>
<f:value>MC</f:value>
</f:item>
...
<f:select1>
No hard-wired presentation (non-specific controls can be styled with style sheets, or adapted by device)
Less scripting needed
Abstract events ("activate", not "click", etc)
Current HTML events are a disaster
Problems include:
XML markup binding to DOM2 Events
Extensible for new event types
'Abstract' events can replace the old device-dependent ones (e.g. 'activate' instead of 'click')
Independent of scripting language
Can entwine event markup in document, or can separate it out
<a onClick="...javascript..." ...>
becomes
<a ev:event="activate" ev:handler="#myhandler" ...>
or
<ev:listener event="activate"
observer="mylink"
handler="#myhandler"/>
...
<a id="mylink" ...>
Device-independence advantages: more types of events, other types of scripting (e.g. declarative)
XForms processing model is defined in terms of events.
<f:button>
<f:label>Delete</f:label>
<f:delete ev:event="activate" .... />
</f:button>
XForms is not a standalone document format: It needs a host (XHTML, SVG, ...)
There are conformance levels to suit different sorts of devices (Full, Basic)
Forms controls may be replaced by a different set (e.g. SVG widgets): this is aided by the event-driven processing model.
There is more...
Current status: preparing for CR; several implementations pre-announced.
Will be adopted in XHTML 2 (in preparation)