XForms seem like such a good idea. With declarative binding of form fields directly to XML document elements, you can implement an XML-centric XFormx/REST/XQuery (XRX) architecture and avoid a bunch of complex server-side code: no Javabeans needed to map HTML form fields to Java objects, and no object-relational mappings to persist the data. Use some XSLT to create XForms from a schema, and you could eliminate most of the custom programming needed to collect, store, and display business information.
So why — nearly 10 years after the initial XForms recommendation — why aren’t XForms being used everywhere? Our recent experience on a research project provides a clue.
First, XForm implementations are lagging. There are arguably only a couple robust implementations on the market: the rest are little more than tinker toys that are extremely limited and fragile. In addition, the implementations have enough extensions and different interpretations of the standard that code portability is non-existant, so you’re locked into a product. This is a far cry from JSF, which has more than a dozen implementations that are more or less interchangeable. The paucity of good implementations is an immediate problem for a development project, but it is really just a symptom of a deeper issue.
The problem with this deeper issue is that it will be very slow to be resolved, if it is resolved at all. If the only issue with XForms was in weak implementations, a new development project might be willing to bet on rapid improvements driven by high demand. With deeper issues at play, I wouldn’t bet on it.