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:
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:
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:
XForms processing is similar, but combines input and output into the same tree:
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.
Other than a few special cases (submit and reset) the way to make
today's web forms do something is through scripts attached to
"intrinsic" event attributes like
onFocus. With the
mission of reducing the need for scripts, the HTML Working Group and
XForms Working Group have jointly developed a general purpose event
framework called XML
Events. It provides an XML interface to DOM Level 2 STYLE
events. It also enables the definition of markup-based
(a.k.a. script-free) XForms Actions.
Using an element-based declarative syntax, XForms authors can:
In this example, a form authored for a resource-limited device might wish to recalculate only when a trigger is activated:
<xforms:trigger> <xforms:label>Click to Recalculate</xforms:label> <xforms:action ev:event="xforms-activate"> <xforms:recalculate/> </xforms:action> </xforms:trigger>
(Note that the
xforms prefix represents the XForms namespace and
ev prefix represents the XML Events namespace.)
While the XForms language is suitable for inclusion in any number of other XML document formats, the sweet spot is its combination with XHTML. Working Drafts of XHTML 2.0 indicate that the old forms technology will not be included in the standard, being replaced by XForms.
The following example will walk through a basic form -- collecting a credit card number in the simplest way possible.
In XHTML, a form is completely enclosed within
<form>...</form> tags. In contrast, the
XForms solution separates purpose, represented by the "XForms Model"
(the name for the non-visible form data plus annotations),
from presentation, represented by the form controls. This means that
adding a single form to a containing document usually involves
inserting markup in multiple places.
The XForms Model belongs in the header section or
element of XHTML:
<html xmlns="http://www.w3.org/2002/06/xhtml2" xmlns:xforms="http://www.w3.org/2002/08/xforms/cr"> <head> <title>Example of XHTML plus XForms</title> <xforms:model id="myform"> <xforms:submission action="https://example.com/cc-submit"/> </xforms:model> </head>
Additionally, form controls belong alongside other markup in the visible portion
of the document, which means the
<body> element in XHTML:
... <p>Enter your credit card number below</p> <xforms:input ref="cc"> <xforms:label>Credit Card:</xforms:label> </xforms:input> <p>...</p> <xforms:submit> <xforms:label>Submit</xforms:label> </xforms:submit> ...
Initially, HTML forms didn't associate any kind of field-level
label with form controls, except for physically positioning the
labels near the controls, which was especially difficult for
non-visual browsers to interpret. Later versions added an optional
label wrapper, but this technique never gained widespread usage. Now
in XForms, every form control element has a required
label child element, which contains the associated
Upon submit, the XForms Processor would deliver serialized instance data -- which looks something like
<instanceData> <cc>123423453456</cc> </instanceData>-- where the element name is determined by the binding expression attached to the
inputelement. In more advanced settings, separate instance data can define arbitrarily complex XML structures processed through XForms.
What does the future hold for XForms? One certainty is that connected devices are becoming more diverse than ever, appearing in all shapes and sizes. Web forms no longer lead sheltered lives on the desktop. By offering a more flexible, device-independent platform, XForms will provide interactivity on such devices.
Most organizations now have substantial investments in XML. Since XForms technology reads and writes XML instance data, it enables existing investments to be leveraged as building blocks in a larger system more smoothly than with ordinary XHTML forms. Additionally, Web Services (or the Semantic Web, depending on your upbringing) will increase the amount of information interchange over the Web, which will in turn increase the need for information to be entered -- through XForms.
Those who have struggled with traditional forms and associated scripting will appreciate the consistent set of form controls and declarative actions in the specification, as well as the powerful and familiar XSLT-like processing model. Calculations, validations, and business logic will also be expressible without scripts.
Updated forms are one of the major changes in XHTML 2.0, the most significant change to HTML since its conception in 1993. Developers and users alike are looking forward to the final W3C Recommendation for XForms.
The primary source for information on XForms is the www-forms mailing list. To subscribe, send an email to firstname.lastname@example.org with the word "subscribe" in the subject line (include the word "unsubscribe" if you want to unsubscribe). The archive for the list is also accessible online.
To play with the latest XForms specification, you can use the latest published Schema, or try out one of the following early implementations:
The open source X-Smiles browser supports an impressive array of standards, including XForms, SVG, SMIL, and XSL formatting objects. E-XMLMedia has developed a Java applet-based version, which is available as a commercial product, with an evaluation version available upon request. Additionally, Mozquito is working on a Flash implementation, with details posted on an editable weblog done in XForms. (Warning: this link requires an XForms browser) More implementations are coming online soon.
XML.com Copyright © 1998-2006 O'Reilly Media, Inc.