W3C Logo

XForms Requirements

W3C Working Draft 21 August 2000

This Version:
http://www.w3.org/TR/2000/WD-xhtml-forms-req-20000821
Latest Version:
http://www.w3.org/TR/xhtml-forms-req
Previous Version:
http://www.w3.org/TR/2000/WD-xhtml-forms-req-20000329
Editors:
Micah Dubinko (Cardiff) <mdubinko@Cardiff.com>
Sebastian Schnitzenbaumer (Mozquito Technologies) <schnitz@mozquito.com>
Malte Wedel (Mozquito Technologies) <malte@mozquito.com>
Dave Raggett (W3C/HP) <dsr@w3.org>

Abstract

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.

Status of this document

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.

Table of Contents

1. Introduction (Informative)

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.

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

1.2 Target Audience

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.

2. Charter and Basic Requirements (Normative)

2.1 Defined in XML, usable in XML

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.

2.2 W3C Integration

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:

P3P

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.

XML Schema

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.

2.3 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.4 Ease of Authoring

XForms should be straightforward to author by hand with a simple text editor, in order to encourage migration from existing HTML forms.

2.5 Separate Purpose from Presentation

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.

2.6 Device 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 Web enabled devices, including conventional browsers, TV sets, set top boxes, palmtops and mobile phones.

2.7 Scripting Interfaces

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.

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

2.9 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. XForms Model Requirements (Normative)

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.

3.1 Data Types

XForms will provide a set of common data types, and may facilitate the construction of custom data types.

3.2 Data Type Identifiers

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.

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 will be able to send the submitted form instance data to the server as an XML document.

3.5 Calculations and Expressions

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.

3.6 Data Value and Form Control Dependencies

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.

3.7 Expandable Form Control Groups (Arrays)

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.

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.

3.10 Confidence Scores

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

4. User Interface Requirements (Normative)

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

4.4 Support More Input 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 (Informative)

XForms will be designed with the following features in mind, however these areas will not be addressed in the first release.

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 Representing Ambiguities

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.

5.6 Digital Signatures

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.

6. Acknowledgments (Informative)

This document was written with the participation of the members of the XForms Working Group (listed in alphabetical order by company):

Invited Experts

7. References (Informative)

[AUTHFORM]
"User Agent Authentication Form Elements", Scott Lawrence, Jim Gettys, Paul Leach, 3 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 the W3C on 3 February 1999.
Available at: http://www.w3.org/MarkUp/Group/Contrib/Lawrence/authform-980903.html (W3C members only)
 
[FML]
"Forms Markup Language (FML) 1.0", Sebastian Schnitzenbaumer, Malte Wedel, Muditha Gunatilake, Josef Dietl, 9 September 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.com/documentation/spec_xhtml-fml.html
 
[FORMSHEET]
"Formsheets and the XML Forms Language", Anders Kristensen, 11 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
 
[FUTUREFORMS]
"The future of HTML Forms", Dave Raggett, 16 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)
 
[XFA]
"XFA-Template Version 1.0", Gavin McKenzie, 14 June 1999.
"XFA-FormCalc Version 1.0", Gavin McKenzie, 14 June 1999.

These documents describe the "XML Forms Architecture", an 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 the W3C on 14 May 1999.
Available at: http://www.w3.org/1999/05/XFA/xfa-template.html(XFA-Template)
Available at: http://www.w3.org/1999/05/XFA/xfa-formcalc.html (XFA-FormCalc)
 
[XFDL]
"Extensible Forms Description Language (XFDL) 4.0", John Boyer, Tim Bray, Maureen Gordon, 2 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 the W3C on 2 September 1998.
Available at: http://www.w3.org/TR/NOTE-XFDL