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.
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
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.
example, the specification permits date data-types to be entered through user-friendly
interfaces like pop-up calendars. The specification gives implementers wide latitude
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
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
that forms become usable across a wide variety of devices, since each device can tailor
controls for their own unique requirements. For graphic designers desiring greater
over appearances, CSS styling is in full force. But even without CSS styling, an attribute
appearance provides a rough indication of how the form control should be
rendered (either "minimal", "compact", or "full") without crossing the line and getting
<output> is a new addition in XForms. It provides the
display of form data within ordinary inline text. For example, an order summary might
"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
platforms with sufficient hardware support, even video, 3d, and other exotic input
One form control is not found in XForms -- an equivalent of the HTML
type="hidden">, which authors frequently use to maintain state information on
the client. As noted earlier, XForms processing maintains instance data in memory,
makes it possible to store structured information rather than primitive name-value
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.
Actions sans Script
Other than a few special cases (submit and reset) the way to make today's web forms
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:
- set focus to a form control
- display a message to the user
- navigate to a new URI (in the same or a new window)
- change the value of an instance data node
- force a recalculation, revalidation, or screen refresh
- submit or reset all or a portion of the instance data
- perform other actions to deal with scrolling and manipulating repeating line item tables
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 the
ev prefix represents the XML
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
tags. In contrast, the XForms solution separates purpose, represented by the "XForms
(the name for the non-visible form data plus annotations), from presentation, represented
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 within the
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
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
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
input element. 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.