Marc van Neerven

The second life of XForms

Contrary to HTML 5 forms, which presents only a number of controls, XForms gives us a complete, MVC-style application model with built-in validation, support for multi-step forms (Wizards), repeating structures, a complete submission module (HTTP, Web Services, REST, and more), all using pure, fully self-contained, declarative XML.

The W3C Forms Group initially designed XForms to be a replacement for the severely limited HTML forms specification. This plan was ambitious, and soon turned out to be unrealistic, considering the incompatibility with HTML forms and the migration concerns involved with that, but also the somewhat higher (perceived) complexity of the technology, and the fact that mainstream HTML developers simply wouldn’t be eager to adopt it. The debate between W3 and the WHATWG, and the resulting drop of the XHTML 2.0 spec in favor of HTML 5 (early 2009) then killed XForms.

Or so they say. Several articles have been written to declare XForms dead, and some of them even use good arguments.

When you think of XForms as a client-technology embedded in the major browsers, that is.

Of course, those with knowledge of what’s really happened would immediately respond that XForms 1.1 has become an official recommendation after XHTML 2 has been dropped, and the Forms Working Group is still working on 1.2 and 2.0…

However, the Working Group has not been very loud on being robbed of a natural habitat. Life went on, and the group was rechartered for two more years in 2010, but without much buzz. As some of us have pointed out, the XML Community simply lacks good marketing…

From client to server

Several vendors, including IBM, Orbeon, Betterform and Seneca, have now embraced XForms as a server-technology, and it is not without reason that server-side implementations are now emerging.

An interesting article was written about the problems with client-side XForms implementations, focusing on the vulnerability of applications relying solely on client-side validations. I would like to add a few more compelling reasons for server-side implementation here:

• Client-side XForms exposes your data model, possibly including sensitive information and business logic. When using server technology, the actual model and business rules are mostly hidden.
• The XForms spec is intended to be device-neutral. This means that an XForms processor should have separate tiers for data, compute and rendering. In fact, it shouldn’t be that difficult to use the same processor but render to other devices.
• HTML 5 is hot, and so is jQuery. When the XForms Engine runs as a server technology however, any other cool rendering technology can be plugged in as soon as it becomes available. XForms documents themselves are not in danger when some cool new client technology comes around to tempt us, because of their abstract, device-neutral character.   

The XForms specification has been worked upon for ten years, and provides a solid foundation for complex digital forms. There is an active community working on implementations and evangelism. Also, a number of vendors is actively involved in extending the spec, cooperating with the W3C, in order to push the standard forward.

XForms is very much alive! It is about time more people knew about it.