W3C Logo

XForms Requirements

World Wide Web Consortium Working Draft 29 March 2000

This Version:
Latest Version:
Previous Version:
Micah Dubinko (Cardiff Software) <mdubinko@cardiff.com>
Sebastian Schnitzenbaumer (Stack Overflow) <schnitz@overflow.de>
Malte Wedel (Stack Overflow) <malte@overflow.de>
Dave Raggett (W3C/HP) <dsr@w3.org>


Forms were introduced into HTML in 1993 and have proven to be a valuable part of many Web pages. The experience of the last few years has led to demands for improvements to HTML forms. XForms are a major revision of HTML Forms. Key goals for the next generation of web forms include ease of migration, improved interoperability and accessibility, enhanced client/server interaction, advanced forms logic, support for internationalization and greater flexibility in presentation.

Status of this document

This is a public W3C Working Draft on requirements for the next generation of web forms. It is intended for review by W3C members and other interested parties. The document provides an overview of the requirements currently under discussion within the Forms Subgroup of the HTML Working Group.

This Working Draft may be updated, replaced or rendered obsolete by other W3C 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 document is work in progress and does not imply endorsement by the W3C membership or the HTML Working Group (members only).

This document has been produced as part of the W3C HTML Activity. The goals of the HTML Working Group are discussed in the HTML Working Group charter (members only).

Please send detailed comments on this document to www-html-editor@w3.org. We cannot guarantee a personal response, but we will try when it is appropriate. Public discussion on HTML features takes place on the mailing list www-html@w3.org.

[Ed. The forms public mailing list is www-forms@w3.org.]

Table of Contents

1. Introduction

After careful consideration, the HTML Working Group has 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. 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 very broad spectrum of form applications.

This document provides a comprehensive set of requirements for 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 to the capabilities of different platforms.

1.1 Rationale

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 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 data, logic and presentation. The same form will be accessible 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 itself, 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 appropriate fields are filled out and that the 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.

1.2 Target Audience

The main target audience for XForms is HTML 4 authors familiar with forms. XForms will make it simpler to build forms including the business logic, calculations, and form processing that in many cases has been done with client-side scripting.

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. By providing a vendor-neutral data model layer, XForms will provide an avenue for interoperability between various forms implementations.

2. Charter and Basic Requirements

2.1 Defined in XML, usable in XML

XForms should be an application of XML 1.0 plus Namespaces. It should be possible to define a rich form, including validations, dependencies, and basic calculations without the use of a scripting language. XForms should be usable in XHTML and other XML-based languages, such as SVG. XForms should be usable by clients without XHTML capabilities.

2.2 Migration from HTML 4

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.

2.3 Ease of Authoring

XForms should be straightforward to hand author, thus further encouraging migration from existing HTML forms.

2.4 Separate Purpose from Presentation

XForms fields should not be bound to a particular interface representation. Instead the field should state the nature of the task 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.

2.5 Integrate with DOM

It should be possible to access and manipulate forms via the XML Document Object Model. 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 DOM convenience methods specific to forms will be added.

2.6 Device and Application Independence

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 devices.

2.7 Unicode, Internationalization, and Region Independence

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 field until their final destination and vice versa. It should be possible to 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 fields taking the user's locale into account. Additionally, in forms designed for international access, labels, sizes and input constraints for subfields should be able to adapt to the locale.

2.8 Modular Construction

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.

3. Logic and Data Model Requirements

3.1 Data Types

XForms should define a set of common data types as well as a mechanism for authors to specify custom data types. Data types should be defined with basic users in mind.

3.2 Data Type Libraries

XForms should include a means for reuse of server-side code for processing subforms. It should be possible to uniquely and persistently name various data types.

3.3 Input Validations

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.

3.4 Send XML to Server

In addition to legacy formats, XForms should be able to send submitted form data back to the server as well-formed XML.

3.5 Calculations and Expressions

XForms should include simple client-side calculations and expressions based on entries in form fields. Common tasks like summing multiple fields 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.

3.6 Field and Data Dependencies

XForms should be able to express dependencies between fields. It should be possible to constrain a field so that it can only accept input if another specific field has accepted input. It should be possible to bind two or more fields to the same data value, so that if the value in one field is updated, then the related form fields also take that value.

3.7 Expandable Field Groups (Arrays)

For field 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.

3.8 Security Features

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.

3.9 Saving and Resuming

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.

4. User Interface Requirements

4.1 Provide Functional Equivalents of HTML 4 Form Controls

Every form of user interaction defined in HTML 4 forms should be possible with XForms.

4.2 New Form Controls

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.

4.3 Support Multiple Pages per Form, and Multiple Forms per Page

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 data models should be able to exist within the same Web page.

4.4 Support More Devices

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.

4.5 Layout/Alignment Issues

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.

5. Future Considerations

5.1 Custom Defined Controls

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.

5.2 Further GUI Enhancements

Further research into various additional graphical elements that will be useful as a part of XForms.

5.3 Voice Enhancements

Further research into ways to make XForms more useful to aural user agents.

5.4 Paper Enhancements

Further research into ways to make XForms more useful to paper processing and OCR user agents.

5.5 Digital Signatures

Further research into what is needed to apply digital signatures to form presentation and data.

6. Acknowledgments

This requirements document was written with the participation of the members of the Forms Subgroup of the W3C HTML Working Group (listed in alphabetical order):

Frank Boumphrey, HTML Writers Guild
Stewart Butterfield, Communicate.com
Tantek Çelik, Microsoft
Andrew Donoho, IBM
Micah Dubinko, Cardiff Software
Michael Fergusson, Communicate.com
Leigh Klotz, Xerox
Dave Manning, PureEdge
Mike Mansell, PureEdge
Larry Masinter, AT&T
Rob McDougal, JetForm
Gavin McKenzie, JetForm
Steven Pemberton, CWI
T. V. Raman, IBM
Dave Raggett, W3C/HP (W3C staff contact)
Sebastian Schnitzenbaumer, Stack Overflow
Stacy Silvester, Cardiff Software
Malte Wedel, Stack Overflow

7. References

"The future of HTML Forms", Dave Raggett, 16th January 1999.

This is a discussion document setting out some possible directions for the HTML Working Group to consider for the next generation of HTML forms. It is proposed that the group begin work on a public Working Draft setting out requirements for the next generation of HTML forms, with the goal of soliciting feedback from W3C members and the general public, and then to proceed to the development of a proposed recommendation of a form module for use with HTML and other XML formats.
Available at: http://www.w3.org/Markup/Group/WD-forms-ng.html (W3C members only)
"XML Forms Architecture (XFA) 1.0", Gavin McKenzie, 14th June 1999.

The document "XFA-Template" describes the open and extensible modeling of secure forms with high fidelity composition, automated calculation and validation, pluggable user-interface components, and flexible data handling. The document "XFA-FormCalc" describes a simple scripting language optimized for creating electronic-form centric logic and calculations. XFA provides for the specific requirements of electronic forms and the applications that use them. XFA addresses the needs of organizations to securely capture, present, move, process, output and print information associated with electronic forms.
Submitted to W3C 14th May 1999. Available at: http://www.w3.org/1999/05/XFA/xfa-template.html(XFA-Template)
http://www.w3.org/1999/05/XFA/xfa-formcalc.html (XFA-FormCalc)
"Forms Markup Language (FML) 0.8", Sebastian Schnitzenbaumer, Malte Wedel, Muditha Gunatilake, 24th June 1999.

This document describes an XML syntax for a Forms Markup Language. The purpose of FML is to redefine and enhance the representation and handling of web application interfaces in the tradition of the HTML 4.0 forms tagset. Key problems for FML to solve are the definition of dynamic forms, online wizards and web applications that cover multiple screen pages but originate from a single FML document, including input validation, navigation, event handling, template management and run-time calculations.
Available at: http://www.mozquito.org/xhtml-fml08
"Extensible Forms Description Language (XFDL) 4.0", John Boyer, Tim Bray, Maureen Gordon, 2nd September 1998.

This document describes an XML syntax for the Extensible Forms Description Language (XFDL). The purpose of XFDL is to solve the body of problems associated with digitally representing complex forms such as those found in business and government. The requirements include support for high precision layout, supporting documentation, integrated computations and input validation, multiple overlapping digital signatures, and legally binding auditable transaction records, by maintaining the whole form as a single unit such that digital signatures can capture the entire context of transactions.
Submitted to W3C on 2nd September 1998. Available at: http://www.w3.org/TR/NOTE-XFDL
"Form-based Device Input and Upload in HTML", James Salsman, 2nd July 1999.

Proposes an extension to the HTML INPUT TYPE=FILE form element specified in RFC 1867 to allow information providers to express requests for uploads from audio and other devices uniformly. Motivations, including language instruction assistance, voice transcription, and other applications, conclude.
Submitted to W3C on 2nd July 1999. It can be found at: http://www.w3.org/1999/07/NOTE-device-upload-19990706
"Formsheets and the XML Forms Language", Anders Kristensen, 11th May 1999.

This Paper describes a means to construct data for submission to a server from an XML form using a stylesheet-like mechanism. This paper was presented at the WWW8 conference held in May 1999.
Available at: http://www.hpl.hp.co.uk/people/ak/doc/XForm.html
"User Agent Authentication Form Elements", Scott Lawrence, Jim Gettys, Paul Leach, 3rd September 1998.

This document proposes a new HTML capability to aid in the development of authenticated web user interfaces. This proposal suggests extensions to HTML forms to overcome their present security problems by integrating them with HTTP (or other security sublayer) mechanisms. It calls for a new type of form; the AUTHFORM and new values for the TYPE attribute of the INPUT element and SELECT block.
Submitted to W3C on 3rd February 1999. Available at: http://www.w3.org/Markup/Group/Contrib/Lawrence/authform-980903.html (W3C members only)