XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.


What Are XForms

September 11, 2002


Think about how many times a day you use forms, electronic or otherwise. On the Web, forms have become commonplace for search engines, polls, surveys, electronic commerce, and even on-line applications. Nearly all user interaction on the Web is through forms of some sort. This ubiquitous technology, however, is showing its age. It predates XML by half a decade, which is a contributing factor to some of its limitations:

  • Poor integration with XML
  • Limited features make even common tasks dependent on scripting
  • Device dependent, running well only on desktop browsers
  • Blending of purpose and presentation
  • Limited accessibility features

A new technology, XForms, is under development within the W3C and aims to combine XML and forms. The design goals of XForms meet the shortcomings of HTML forms point for point:

  • Excellent XML integration (including XML Schema)
  • Provide commonly-requested features in a declarative way, including calculation and validation
  • Device independent, yet still useful on desktop browsers
  • Strong separation of purpose from presentation
  • Universal accessibility

This updated article gives an introduction to XForms, based on the 21 August 2002 Working Draft, which is described as being a close precursor to a Candidate Recommendation draft.

How it Works

Forms are for collecting data, so it's not surprising that the most important concept in XForms is "instance data", an internal representation of the data mapped to the familiar "form controls". Instance data is based on XML and defined in terms of XPath's internal tree representation and processing of XML.

It might seem strange at first to associate XPath and XForms. XPath is best known as the common layer between XSLT and XPointer, not as a foundation for web forms. As XForms evolved, however, it became apparent that forms needed greater structure than was possible with simple name-value pairs. With structured data comes the need to reach into the instance data to connect or "bind" form controls to specific parts of the data structure, hence XPath.

Since XForms and XSLT are related through XPath, it is interesting to compare the two technologies. XSLT is usually described in terms of three trees, usually produced by parsing XML documents:

XSLT with labeled'source tree', 'stylesheet tree', and 'result tree' and arrows
  1. From input sources, typically documents, a "source tree" and "stylesheet tree" are parsed into memory.
  2. Processing of these two trees forms a third tree, the "result tree".
  3. Upon completion of processing, the result tree is serialized, typically to a new XML document.

XForms processing is similar, but combines input and output into the same tree:

a single tree, labeled 'instance data', with arrows in and out
  1. From an input source, either inline or an XML document on a server, "instance data" is parsed into memory.
  2. Processing of the instance data involves interacting with the user and recording any changes in the data.
  3. Upon submit, the instance data is serialized, typically as XML, and sent to a server.

Related Articles

What's new in the HTML family Interactive Web Services with XForms

Getting started with XSLT and XPath

Toward an XPath API

What is XSLT?

Comment on this article Got questions about XForms? Ask them here.
Post your comments

Like XSLT, the input and output to the system usually consists of XML files. For compatibility with existing form processing, XForms can also serialize submitted data as multipart/form-data, or url-encoded (even down to the detail of whether to use & or ; as a separataor character).

Processing an HTML or XHTML form involves more than simply collecting data. Crucial for forms is additional processing, such as calculations, validations, and keeping track of which form controls are relevant, read-only, or required. In HTML, such processing is accomplished through attached scripts. The goal of XForms is to provide the 20% of necessary functionality to eliminate 80% of the need for scripting. This happens through two kinds of annotation of the XML form data: XPath-based properties and XML Schema data-type support.

XPath annotations, which can be attached to any node in the instance data, provide a framework for supporting calculations, specific validations, read-only data, and visibility of controls. Separately, XML Schema data-types provide additional data collection parameters such as patterns (like, say an email address) and length restrictions. A conformance profile called XForms Basic, however, avoids the use of most of XML Schema. Taken together these two W3C technologies are the basis for creating powerful forms that aren't so dependent on script.

Meet the Form Controls

The most popular section of the XForms specification deals with the new form controls, or user interface components that deal with interactive data entry and display. XForms offers what web users have come to expect, plus a few surprises.

XForms form control Closest XHTML equivalent Description
<input> <input type="text"> For entry of small amounts of text
<textarea> <textarea> For entry of large amounts of text
<secret> <input type="password"> For entry of sensitive information
<output> N/A For inline display of any instance data
<range> N/A For smooth "volume control" selection of a value
<upload> <input type="file"> For upload of file or device data
<trigger> <button> For activation of form events
<submit> <input type="submit"> For submission of form data
<select> <select multiple="multiple">
or multiple
<input type="checkbox">
For selection of zero, one, or many options
<select1> <select> or multiple
<input type="radio">
For selection of just one option among several

The text controls -- <input>, <textarea>, and <secret> -- behave essentially as in HTML, when attached to a string data-type. More interesting possibilities become available with richer data-types. For example, the specification permits date data-types to be entered through user-friendly interfaces like pop-up calendars. The specification gives implementers wide latitude in this regard, so it will be interesting to see how competitive pressures shape the results.

Text controls also support another important feature: input modes, which are important for entry of many kinds of worldwide text. An appendix in the XForms specification lists some 50 possible input modes, plus an additional ten modifier tokens for options like case conversion, predictive input (used on telephone keypads).

The list controls -- <select>, and <select1> -- both represent the concept of selecting from a list of options without directly indicating an implementation (such as type="radio" in HTML). These provide a higher level of abstraction than that which HTML authors might be used to. The benefit of this design is that forms become usable across a wide variety of devices, since each device can tailor the controls for their own unique requirements. For graphic designers desiring greater control over appearances, CSS styling is in full force. But even without CSS styling, an attribute named appearance provides a rough indication of how the form control should be rendered (either "minimal", "compact", or "full") without crossing the line and getting too specific.

The control <output> is a new addition in XForms. It provides the display of form data within ordinary inline text. For example, an order summary might say "Your order of 7 items totals $99.00", where "7" and "99.00" are each <output> controls mapped to a computed instance data node.

Another new control is <range>, which provides a continuous selection of a value within two extremes.

screen-shot of a range slider control from X-Smiles

Voice browsers and other systems can take special advantage of ranges to provide a more intuitive user experience.

The form control <upload> holds some pleasant surprises for form designers. In addition to allowing file system uploads, this form control specifies connections to scanners and digital cameras, microphones, pens and digitizers, and on platforms with sufficient hardware support, even video, 3d, and other exotic input devices.

example of audio/* input. A drop-list with choices 'From Microphone...', 'From Line In...' and 'Browse...'

One form control is not found in XForms -- an equivalent of the HTML <input type="hidden">, which authors frequently use to maintain state information on the client. As noted earlier, XForms processing maintains instance data in memory, which makes it possible to store structured information rather than primitive name-value pairs. In essence, any instance data not mapped to a form control is "hidden" data.

The XForms specification also provides sophisticated ways to combine form controls, including repeating lists such as found on a purchase order, and portions that show or hide based on various interactions. It is even possible to create multi-page forms that don't need to contact the server when switching pages.

Pages: 1, 2

Next Pagearrow