Someone recently asked me to explain why the XForms way of binding form controls to XML data with XPath was better than, say, using XSLT templates to match data with XPaths and output an XHTML form. Seemed a fair question.
An XSLT describes a transformation step that happens entirely before the user gets involved, so all the limitations of current XHTML forms still applies to the result of the transformation.
In comparison, XForms defines an intelligent, interactive layer that governs the fill experience for the data. Applying an XSLT to data does not, in and of itself, describes what happens as the user interacts with the data to create new content, so the author of the XSLT is left to encode the old script and HTML devices into the XSLT.
XForms standardizes the following:
- schema-based validation as you fill out the form
- dynamic validation constraints applied as you fill out the form
- calculated dependent values (like tax and total values on a purchase order)
- accessibility text
- access to the web services to let an SOA enrich the fill experience
- preservation of data hierarchy in the UI
- access to template-based UI repetition responsive to data mutations
- user interface switching (presenting panels of controls conditionally or in sequence)
- dynamic user interface properties (readonly, visibility/display)
- XML data submissions to the Web 2.0 server tier
Not only does XForms standardize these things, but it standardizes how they work together.
To further drive home the point, note that XSLT transformation could actually be used as a sympathetic technology with XForms. You could, for example, write an XSLT that transforms an XML Schema into data+XForms rather than data+DHTML. Then, you'd still get all of the above value adds because XForms is a standardized interactivity layer that describes what happens after the XSLT generates the initial rendition.[Read More]