Copyright© 2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
Forms were introduced into HTML in 1993. Since then they have gone on to become a critical part of the Web. The existing mechanisms in HTML for forms are now outdated, and W3C has started work on developing an effective replacement. This document outlines the requirements for "XForms", W3C's name for the next generation of Web forms.
This document is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current public W3C Working Drafts can be found at http://www.w3.org/TR.
This specification describes requirements for the next generation of Web forms. This document has been produced as part of the W3C work on XForms, following the procedures set out for the W3C Process. The authors of this document are members of the W3C XForms working group (W3C Members only). This document is for public review, and comments and discussion are welcomed on the public mailing list <www-forms@w3.org>. To subscribe, send an email to <www-forms-request@w3.org> with the word subscribe in the subject line (include the word unsubscribe if you want to unsubscribe). The archive for the list is accessible online.
After careful consideration, the HTML Working Group decided that the goals for the next generation of forms are incompatible with preserving full backwards compatibility with browsers designed for earlier versions of HTML. A forms sub-group was formed within the HTML Working Group, later becoming the XForms Working Group. It is our objective to provide a clean new forms model ("XForms") based on a set of well-defined requirements. The requirements described in this document are based on experience with a broad spectrum of form applications.
This document provides a comprehensive set of requirements for the W3C's work on XForms. We envisage this work being conducted in several steps, starting with the development of a core forms module, followed by work on additional modules for specific features. The Modularization of XHTML provides a mechanism for defining modules which can be recombined as appropriate for the capabilities of different platforms.
Web forms are being used in various contexts as a standardized mechanism for bidirectional data exchange over the Web. In many occasions, it is desirable to enable an open data dialog between the recipient of a hypertext document and the sender. Forms need to provide effective support for various kinds of data exchange. The design of XForms focuses on the increasing demands for improved human-computer interaction as well as the interaction mechanisms between user agents (e.g. browsers) and servers.
The design of XForms focuses on the increasing demands for improved human-computer interaction as well as the interaction mechanisms between the browser (user agent) and the server.
To enable Web content developers to meet these challenges XForms will be designed to cleanly distinguish between form instance data, form description (called the XForms Model), and form presentation (called the XForms User Interface). The same form will be accessible on a full screen display, as a sheet of paper or using a handheld computer resting on your palm.
To meet the goals for richer presentation XForms will be designed for integration with other XML tag sets, such as XHTML, SVG for graphics and SMIL for multimedia forms. You will be able to use style sheet languages such as CSS and XSL to finely tune the presentation.
As the cost and size of Web servers continues to shrink, single chip implementations are now practical, and we can soon expect to see all kinds of devices with embedded servers. XHTML will be used for controlling such devices, reducing the need for custom device drivers. XForms will be designed to provide the richer user interface these applications will need.
It is generally best to catch input errors early. This can be achieved with form logic that works with the user to ensure that the form data values satisfy the appropriate consistency checks. For phone numbers and addresses, the checks will vary from one part of the world to another.
Complex forms are best presented as a sequence of sections, one section at a time. The ability to download the entire sequence in a single file makes it easy to fill out the form without a real-time connection to the Web server, and avoids the inevitable delays in reestablishing a connection to the server for each section.
For some applications, the process of filling out the form will be interleaved with searching for relevant information. This motivates the development of the means to suspend a form and to later resume filling it out, perhaps a considerable time later. This could occur explicitly at the users request, for instance, when filling out a tax return, or automatically when moving from one page to another on a home shopping Web site.
XForms provide considerable benefits compared with classic XHTML forms. In particular the separation of the purpose from the presentation of a form enables a separation of concerns such that differing skills can be applied to the design of a form. These skills may be embodied in a single person or many depending on both the sophistication of the Form being designed as well as the skills of individuals involved in the design process.
Individuals familiar with HTML 4 Forms will find XForms both more powerful as well as simpler. Specifically, XForms will make it simpler to build forms including the business logic, calculations, and form processing that in many cases prior to XForms has been done with scripting. The two primary roles associated with XForms authoring are the design of the purpose of the form as expressed in a data model as well as the design of the user interface and user interaction.
Server-side programmers are also part of the target audience. In the past, deploying forms on a Web site involved complex server-side scripting to accept, validate, and process incoming data. XForms will make this easier by providing a consistent, XML-based format for incoming data, as well as by providing a rich validation framework.
Finally, application vendors that produce products that interact with forms are part of the target audience. A vendor-neutral XForms model will provide an avenue for interoperability between various forms implementations.
XForms will be an application of XML 1.0 plus Namespaces. It will be possible to define a rich forms, including validations, dependencies, and basic calculations without the use of a scripting language. As an application of XML, it will be possible to combine XForms with other XML based languages such as XHTML.
The development of XForms will require interaction with many other W3C Working Groups. In particular, close coordination will be required with the following two Working Groups:
The XForms Working Group will work with members of the P3P Specification Working Group to define functional requirements for integration of P3P and XForms. Close integration is important to assure that forms designed with XForms for the purpose of collection of personally-identifiable data allow the seamless association of privacy policies and preferences with the data being collected. The P3P specification Working Group will be asked to review the XForms Requirements and XForms Model specification.
To meet the needs for expressing the XForms Model, the XForms Working Group will utilize functionality from XML Schema in addition to developing additional form-specific properties. The XML Schema Working Group will be asked to review the XForms Requirements and XForms Model specification.
XForms should be designed in such a way as to encourage users to make use of the new capabilities, rather than lingering on existing form technologies. Likewise, the design should encourage implementors to deploy user agents that implement XForms.
XForms should be straightforward to author by hand with a simple text editor, in order to encourage migration from existing HTML forms.
XForms data values should not be bound to a particular interface representation. Instead the XForms Model should represent the nature of the tasks the user is being asked to perform. The "purpose" of a form control may be the same on various devices, whereas the rendering may vary based on different capabilities.
XForms should express the navigation paths within a form without implying specific user interface devices such as a mouse or keyboard. The navigation shouldn't rely on device-specific methods such as use of the "tab"-key.
It should be possible to express forms event handling for a broad range of devices. In previous versions of HTML some events were device-independent (e.g. onfocus, onblur, onchange), while others implied the availability of device-specific features (e.g. onmouseover, ondblclick). Within a single form, it should be possible to exploit events specific to different kinds of Web enabled devices, including conventional browsers, TV sets, set top boxes, palmtops and mobile phones.
It should be possible to access and manipulate forms via a scripting interface. This is needed to allow the construction of specialized forms with behaviors going beyond the limits of the forms language itself. XForms should be accessible as part of an XML document, insensitive to changes in the enclosing document. Additional scripting interfaces specific to forms will be added.
XForms should be fit for usage with non-western character sets, languages, and writing systems, including support for Unicode. It is required that nonwestern characters be preserved from their initial entry in a form control until their final destination and vice versa. It should be possible to provide for entry of data formats that do not force international users to adapt to western data formats if the corresponding data format is substantially different in other regions. Forms designed for international access should to be able validate such data values taking the user's locale into account. Additionally, in forms designed for international access, labels, sizes and input constraints for data values should be able to adapt to the locale.
Since smaller specifications are both easier to understand and easier to implement, XForms should be defined as modular, self-contained documents that can be independently brought to Recommendation status.
XML Forms should be compatible with, build on, and extend (where necessary) the basic concepts, data structures, and data types defined by XML Schemas. XForms should address the needs of HTML authors as well as people who wish to use XForms with data models defined in XML Schema.
XForms will provide a set of common data types, and may facilitate the construction of custom data types.
XForms should include the means to provide globally unique identifiers for types which can be used to establish that a given type is the same as used in other forms.
XForms should be able to express restrictions on user-entered data, with enough sophistication to handle common cases, like "telephone number". XForms should define how the user agent should behave when the user-entered data conflicts with the restrictions defined by a data type.
In addition to legacy formats, XForms will be able to send the submitted form instance data to the server as an XML document.
XForms should include simple calculations and expressions based on form data values. Common tasks like summing multiple data values and calculating sales tax should be possible. The expression syntax needs to be simple enough to be easily parsed and processed by a wide variety of user agents. It should be possible to escape out to a scripting language for advanced processing.
The XForms Working Group is aware of potential overlap with the XML Query Working Group in this area, and will review the documents produced by the XML Query Working Group. The XML Query Group will be asked to review the XForms Requirements and XForms Model specification.
XForms should be able to express dependencies between data values. It should be possible to constrain a form control so that it can only accept input if another specific data value has been filled. It should be possible to bind two or more form controls to the same data value, so that if the data value is updated, then the related form controls indicate that value.
For form control groups that support multiple entries, such as a line item on an order form, it should be possible for the form control to dynamically expand and contract to permit the addition or removal of further items. It should be possible to specify the initial, minimum, and maximum number of entries.
It should be possible to perform secure, protocol-independent form transactions. Current user agents typically implement HTTP authentication with a pop-up window requesting name and password. It should be possible for XForms to be used as a front end for HTTP authentication.
There needs to be a generalized way of preserving the changes the user has made to a form. This will make it possible for a user to save the form, and at a later time, to resume filling it out, perhaps from a different machine and perhaps with a different user interface. The ability to treat forms as persistent objects encapsulating state and behavior is needed for workflow applications where forms are passed from one user to another. It should be possible to merge independent updates to persistent forms in ways specific to individual applications.
Some input modalities (for example, speech recognition, handwriting recognition and optical character recognition) naturally result in uncertainties. Recognition engines may provide a measure of how confident the engine was that a given value was correctly recognized. XForms should provide a means for such confidence scores to be associated with form instance data and made available to servers when processing the form data. The representation of ambiguities is something that is potentially harder to deal with and falls under the section on "future considerations".
Every form of user interaction defined in HTML 4 forms should be possible with XForms.
Compared to current Web form technology, XForms should define richer form controls to match the expectations of designers, and to provide richer functionality for data acquisition. Designers should be given greater control over the visual appearance of form controls.
It should be possible for a form to be presented as two or more pages. This requirement permits the form to be treated as a single unit or as several parts. The form's logic should apply regardless of how it is split up.
Multiple independent forms should be able to exist within the same Web page.
Forms need to support a wide range of data acquisition techniques in addition to plain text. For instance, to enable the input of files, such as audio files, and the input of data streams from devices such as cameras, microphones and scanners. Also under consideration are pen-based inputs, which would allow signatures and other simple drawings to be entered directly into a form equipped with a suitable drawing canvas.
XForms should have no dependency on a particular presentation technology, for example XHTML tables.
We will investigate ways of achieving richer form layout and alignment on a wide variety of devices.
XForms will be designed with the following features in mind, however these areas will not be addressed in the first release.
There should be a way to define new form controls (perhaps using other markup languages such as SVG, perhaps with bitmap images) offering a custom look and feel but integrated into the forms model so that they internally behave and react like a standard form control.
Further research into various additional graphical elements that will be useful as a part of XForms.
Further research into ways to make XForms more useful to aural user agents.
Further research into ways to make XForms more useful to paper processing and OCR user agents.
Some input modalities (for example, speech recognition, handwriting recognition and optical character recognition) naturally result in uncertainties and ambiguities. Did the user say "Boston" or "Austin" for the destination city? Study is needed into ways to represent such ambiguities in form instance data, and to make this available to servers when processing the form data.
Further research into what is needed to apply digital signatures to form presentation and data, possibly including the preservation of the form presentation exactly as the user experienced it.
This document was written with the participation of the members of the XForms Working Group (listed in alphabetical order by company):