The State of the Art
XForms can seem inordinately large and complicated at first blush, but much of the complexity can be attributed to integrating the model into the equation. Unlike scripted XHTML forms, once you've done the initial work to build an XForms document, adding new controls is surprisingly easy. Therefore, most working XForms (with many controls and components) will be easier to maintain than the equivalent scripted code applications.

What's more, because XForms is 100% XML based, you can use XSLT to generate an XForms document from one or more source XML files, perhaps with some schema filtering thrown in to determine which components best match the elements described by the schema.

The XForms specification itself is in Candidate Recommendation status. It may hold there until the XPath 2.0 specification is completed, because there are some compelling reasons to bind these two standards together, including external function definitions and inline regular expression support in XPath.

Implementation-wise, XForms support is perhaps not yet where it needs to be, though that's changing. IBM has begun work on the specification with its XForms Processing Center. In addition to supporting the XForms 1.0 standard, IBM's XPC also incorporates a ListView type control extension and a way to invoke Web services to send and retrieve content. This latter point is especially important because it makes it possible to build very robust client/server applications solely through an XForms interface.

The Novell XForms Technology Preview provides a stand-alone XForms viewer, designed to work with "pure" XForms (i.e., those that aren't embedded within HTML) though support for the latter is coming. The Novell implementation does include extensive CSS support, however, so the lack of an HTML substrate is not necessarily a major limitation.

Perhaps the most full-featured XForms viewer to date is the x-port XForms viewer. It provides both pure XML and embedded HTML support (with associated CSS in both cases), and runs as a plug-in within IE6. One drawback is that you must include both the <object> reference for the player and a processing instruction in the body of the XForm to use X-Port, though that may change after the specification becomes more mature.

As XForms evolves, it will likely move into two different realms. The Scalable Vector Graphics working group of the W3C is exploring ways to incorporate XForms into SVG 1.2, providing at least basic support for several critical components, which you can then override with custom graphics.

The next likely venue for XForms is in the wireless/mobile phone market. It's much easier to build XForms interpreters than to support a full-bore scripting language. XForms could quickly replace the cumbersome and awkward WAP/WML standard. Given the obvious synergy between XForms and VoiceXML, it is also likely that the next version of VoiceXML will be rebuilt along XForms lines, though maintaining a modicum of backwards compatibility.

XCiting XForms
XForms represents both a very old and very new way of programming, a model that can be crafted by hand or generated through transformations with equal ease. As computer architectures tend to move toward dynamic user interfaces, XForms provides a powerful vehicle to create increasingly robust "applications" without huge amounts of fragile scripted code. As a W3C standard, such applications have the implicit advantage of being platform and software language independent.

If your company deals with complex form information, wants to keep costs down, and needs a solution that can be easily maintained and updated, you could do a lot worse than explore XForms.