What Are XForms
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.
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:
- From input sources, typically documents, a "source tree" and "stylesheet tree" are parsed into memory.
- Processing of these two trees forms a third tree, the "result tree".
- 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:
- From an input source, either inline or an XML document on a server, "instance data" is parsed into memory.
- Processing of the instance data involves interacting with the user and recording any changes in the data.
- Upon submit, the instance data is serialized, typically as XML, and sent to a server.
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
; 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.
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|
|For selection of zero, one, or many options|
|<select1>||<select> or multiple
|For selection of just one option among several|
The text controls --
<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 --
<select1> -- both represent the concept of
selecting from a list of options without directly indicating an
implementation (such as
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.
<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.
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
One form control is not found in XForms -- an equivalent of
<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"
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