The W3C's XForms specifications are aimed to develop the next-generation forms technology for the Web. According to the XForms Working Group's mission statement:

The key idea is to separate the user interface and presentation from the data model and logic, allowing the same form to be used on a wide variety of devices such as voice browsers, handhelds, desktops and even paper.

In his recent IBM developerWorks article, Why XForms?, Elliotte Rusty Harold takes a realistic look at the XForm standard, identifying areas where XForms can be beneficial, while recognizing that for many use-cases, XForms is an overkill.

From its first days, the Web has been torn between idealists and pragmatists. The idealists envision a global, interconnected network of free and open exchange of information with truth, justice, and liberty for all. The pragmatists envision getting their work done before 5:00 p.m. and going home to spend time with their families.

The idealists evangelize technologies like Standard Generalized Markup Language (SGML), Extensible Markup Language (XML), Scalable Vector Graphics (SVG), Cascading Style Sheets (CSS), and Extensible Hypertext Markup Language (XHTML). The pragmatists turn to HTML, JavaScript, tables, and Flash...

The latest bone of contention between the two camps is over the next-generation forms technology: Web Apps 2.0 or XForms.

XForms' idealistic aspirations come from its complete separation of a form's content from a form's presentation. That makes XForms very flexible, but that flexibility comes at the price of increased complexity, according to Harold:

XForms is an idealistic effort to solve many pragmatic problems that bedevil Web developers today. Pragmatic solutions based on incremental improvements to classic HTML forms are good as far as they go, but they don't reach nearly as high as XForms does. However, precisely because XForms reaches higher, it falls farther and makes a bigger thud on impact when it fails.

Harold identifies seven areas where XForms provides unsurpassed capabilities. At the same time, Harold also acknowledges that many of XForms' strengths will only become evident once other technologies, such as voice recognition, become widely used.

The first area Harold explores is the use-case of one form having to support multiple types of input:

XForms is that it's not just for the Web and not just for HTML... XForms is designed to work well in many other environments: mobile phone browsers, audio browsers, and things that aren't browsers at all. For instance, OpenOffice 2.0 uses XForms as its underlying forms technology...

Furthermore, like XML before it, XForms is designed to separate intention from action, meaning from presentation. It's designed to be a generic description of the input a form needs to collect... The same form can be rendered one way in a browser, a different way in a phone tree with touchtone and voice-recognition input, and a third way on paper to be filled out with ink and scanned in using optical character recognition.

The next area Harold explores is the requirement to support input from a variety of devices:

In the near future, the most common device for accessing the Web will be a mobile phone. Perhaps the second most popular device will be a human-powered laptop running a custom version of Linux on an underpowered processor...

XForms make no assumptions about what kind of device is used to fill out the form... For example, a form that asks for a shipping and billing address may appear on one page in a traditional Web browser like Firefox. However, it can easily be split into two successive screens on a smaller device like a mobile phone. It can even be nonvisual if the form is filled out by talking rather than typing.

Next, Harold points to a use-case where machines fill in a form without human intervention:

In this use case, not only is the presentation separated from the markup, but there may not be any presentation. Humans are smart and can use implicit clues like the position of fields on the page to tell what data is expected where. Computers can't: They need more help... The more explicit the form is about what can be entered into it, the easier it will be to automate interaction with the form.

Another XForms strength is support for Unicode, which comes from XForms being based on XML:

Forms uses XML as its underlying serialization form. When a browser or other client receives an XForm from a server, it receives XML. When it sends the form data back to the server, it encodes the data in an XML document. XML documents are Unicode. They can be stored in other encodings, but the translation between those encodings and Unicode is simple and deterministic. When you work with XML, encoding problems go away.

Accessibility is another important consideration for using XForms, according to Harold:

This doesn't just include the obvious categories of blind and physically handicapped users. It means the rest of us, too, because everyone is handicapped some of the time. Many people surf the Web on tiny cell-phone screens with numeric keypads. People may fill out XForms while driving using an audio interface. In an increasing number of jurisdictions, accessibility isn't just a good idea. It's the law.

Form validation was one of the original use-cases of JavaScript. XForms provides built-in form validation on both the client and on the server:

XForms wants to make these [client-side] checks a lot easier to write by making them declarative and more direct. Therefore, they're more likely to be written in the first place... XForms is designed to allow validation on the server side as well as the client.

Another frequent use-case of JavaScript is to relegate to the client some computation, such as simple calculations associated with filling in a form. XForms provides support for reducing client-server round-trips as well:

Currently, this process is implemented with JavaScript; but JavaScript is ugly and hard to maintain. Adding calculation fields that depend on the content of other fields enables a more declarative approach.

What do you think of the trade-off between complexity and increased flexibility in XForms? For browser-based Web applications, do you think that the practical aspects of Ajax will eclipse XForms? Or will XForms thrive in an Ajax-friendly environment?