W3C Working Draft 21 August 2000
Micah Dubinko (Cardiff) <mdubinko@Cardiff.com>
Sebastian Schnitzenbaumer (Mozquito Technologies) <firstname.lastname@example.org>
Malte Wedel (Mozquito Technologies) <email@example.com>
Dave Raggett (W3C/HP) <firstname.lastname@example.org>
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 <email@example.com>. 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 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.
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
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:
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.
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
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
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
4.1 Provide Functional Equivalents of HTML 4 Form Controls
Every form of user interaction defined in HTML 4 forms should be possible
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
Multiple independent forms should be able to exist within the same Web
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.
This document was written with the participation of the members of the
XForms Working Group (listed in alphabetical order by company):
Micah Dubinko, Cardiff
Jen Williamson, Cardiff
Steven Pemberton, CWI (chair)
Najib Tounsi, Ecole Mohammadia d'Ingénieurs, Rabat, Morocco
Driss Eddaifi, Ecole Mohammadia d'Ingénieurs, Rabat, Morocco
Kevin Munroe, Enosys Markets, Inc
Michalis Petropoulos, Enosys Markets, Inc
Peter Stark, Ericsson
Frank Boumphrey, HTML Writers Guild
Dave Raggett, HP/W3C (staff contact)
Roland Merrick, IBM
T.V. Raman, IBM
Linda Welsh, Intel
Gavin McKenzie, JetForm Corporation
Rob McDougall, JetForm Corporation
John McCarthy, Lawrence Berkeley Lab
Frank Olken, Lawrence Berkeley Lab
Ray Waldin, Lexica, LLC
Tantek Çelik, Microsoft
Alex Hopmann, Microsoft
Sebastian Schnitzenbaumer, Mozquito Technologies (co-chair)
Malte Wedel, Mozquito Technologies
Eric Pollmann, Netscape/AOL
Panagiotis Reveliotis, Philips
Roli Wendorf, Philips
Ted Wugofski, Phone.com
David Cleary, Progress Software
Mike Mansell, PureEdge
Dave Manning, PureEdge
Zoe Lacroix, SurroMed Inc.
Leigh Klotz, Xerox
Tom Schnetlage, University of Berkeley
Dan Gillman, Federal Bureau of Labor Statistics
Eliot Christian, US Geological Survey
Ashok Malhotra, XML Schema and XML Query Working Groups (and IBM)
7. References (Informative)
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)
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
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
Available at: http://www.hpl.hp.co.uk/people/ak/doc/XForm.html
"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
Version 1.0", Gavin McKenzie, 14 June 1999.
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)
"Extensible Forms Description
Language (XFDL) 4.0", John Boyer, Tim Bray, Maureen Gordon, 2 September
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