Steven Pemberton, W3C and CWI, Amsterdam
Chair, XForms WG
Separation of content from presentation
Strong typing
XML Submission
Internationalisation
Accessibility
Device independence
Reduced scripting through declarative event handlers
Not a standalone document format
By putting details of the data in the head of the document and binding to controls in the body, the data collected is more obvious, and more reuse is possible.
<head>
<xforms:model>
<xforms:instance>
<age/>
</xforms:instance>
<xforms:submitInfo action="/submit"
method="post" id="sbmt" />
</xforms:model>
</head>
<body>
...
<xforms:input ref="age">
<xforms:caption>How old are you?</xforms:caption>
</xforms:input>
<xforms:submit submitInfo="sbmt">
<xforms:caption>OK</xforms:caption>
</xforms:submit>
...
Optional use of Schema datatypes allows client-side checking.
<xf:model>
<xf:instance href="/cgibin/get-values" />
<xf:schema href="data.xsd" />
...
</xf:model>
Collected data can be sent to the server as XML instance.
<instanceData>
<cc>MC</cc>
<nr>12345678909</nr>
<expires>12/01</expires>
</instanceData>
Better support for character encodings.
Non-specific form controls allow use on accessible devices.
<caption> element present on all controls
<f:selectOne ref="cc">
<f:caption>Credit card</f:caption>
<f:choices>
<f:item>
<f:caption>Mastercard</f:caption>
<f:value>MC</f:value>
</f:item>
...
Non-specific form controls ("selectOne", not "radio", etc)
Non-specific events ("activate", not "click", etc)
<f:button>
<f:caption>Delete</f:caption>
<f:delete ev:event="activate" .... />
</f:button>
Needs a host
Different conformance levels to suit different sorts of devicesz
There is more...