W3C has announced the publication of XForms 1.0 as an approved W3C Recommendation, signifying that the specification is "stable, contributes to Web interoperability, and has been reviewed by the W3C Membership, who favor its adoption by the industry. In contrast to HTML forms in which functional and presentation markup are intertwined, XForms lets forms authors distinguish the descriptions of the purpose of the form; the presentation of the form, and how the instance data are written in XML. By splitting traditional HTML forms into three parts -- XForms model, instance data, and the XForms user interface -- XForms cleanly separates presentation from content. This separation brings new advantages: (1) Reuse: XForms modules can be reused independently of the information they collect; (2) Device independence: user interface controls are abstract -- that is, their generic features are the only thing indicated -- so they can easily be delivered to different devices with different capabilities; (3) Accessibility: separation of presentation from content leaves information more readily available for users of assistive technologies; in addition, the user interface controls encapsulate all relevant metadata such as labels, thereby enhancing accessibility of the application when using different modalities. Practically speaking, XForms technologies make it possible to deliver the same form to a PDA, a cell phone, screen reader or conventional desktop machine, without loss of functionality for the end user." The XForms 1.0 Basic Profile has now been published as a standalone W3C Candidate Recommendation. This profile describes a minimal level of XForms processing tailored to the needs of constrained devices and environments. A brief tutorial XForms for HTML Authors has also been released to support authors; it provides an introduction to XForms and shows how to convert existing forms to their XForms equivalent.

Bibliographic Information

XForms 1.0. W3C Recommendation 14-October-2003. Edited by Micah Dubinko (Cardiff Software), Leigh L. Klotz, Jr. (Xerox Corporation), Roland Merrick IBM), and T. V. Raman (IBM). Version URL: http://www.w3.org/TR/2003/REC-xforms-20031014/. Latest version URL: http://www.w3.org/TR/xforms/. Previous version URL: http://www.w3.org/TR/2003/PR-xforms-20030801/. Also available as a single HTML file, as diff-marked HTML document, and in .ZIP archive format.

XForms 1.0 Basic Profile. W3C Candidate Recommendation 14-October-2003. Edited by Micah Dubinko (Cardiff Software) and T. V. Raman (IBM). Version URL: http://www.w3.org/TR/2003/CR-xforms-basic-20031014/. Latest version URL: http://www.w3.org/TR/xforms-basic/. Previous version URL: http://www.w3.org/TR/2002/CR-xforms-20021112/.

XForms for HTML Authors. By Steven Pemberton (W3C/CWI). Version date: 13-October-2003. Tutorial Introduction. "XForms is the new markup language for forms on the Web. This document is a quick introduction to XForms for HTML Forms authors. It shows you how to convert existing forms to their XForms equivalent. It assumes knowledge of HTML Forms, so is not a beginner's tutorial. Although there is mention of additional facilities of XForms beyond those possible in HTML Forms (marked with an asterisk on the headings), it is not a full tutorial on all features of XForms..."

Related specification: XML Events: An Events Syntax for XML. W3C Recommendation 14-October-2003. Edited by Shane McCarron (Applied Testing and Technology, Inc), Steven Pemberton (CWI/W3C), and T. V. Raman (IBM Corporation). "The XML Events module defined in this specification provides XML languages with the ability to uniformly integrate event listeners and associated event handlers with Document Object Model (DOM) Level 2 event interfaces. The result is to provide an interoperable way of associating behaviors with document-level markup..."

From the Announcement

When HTML forms were introduced to the Web in 1993, they provided a means to gather information and perform transactions. The structure of forms served the needs of many users at that time, as well as the devices used to access the Web.

Now, 10 years later, the original HTML form design is showing its limitations. Users now wish to access the Web through cell phones, handheld devices, and assistive technologies such as screen readers, and authors need more functionality based on their experience with HTML forms and non-Web-based forms technologies. Forms authors are looking to both minimize scripting and maximize reuse of form components, as well as cleanly separate the purpose, presentation and results of a form. And of course, companies which have made the move to XML are looking for ways to integrate forms into their business processes.

W3C's XForms gives authors more power and flexibility while improving the user experience," explained Steven Pemberton, Chair of the W3C XForms Working Group. "The XForms Working Group has provided a model that makes it easy for implementors to develop and reuse form components, integrate them into Web services, and deliver functionality to users and devices previously not possible."

XForms Aids the Author and Improves the User Experience: "XForms allows authors to specify properties of, and relationships between, values being collected, for instance that a particular field must be an email address, that the total amount field is the sum of the individual line items, or that the credit card number isn't required if payment is by cash. These are specified using simple properties such as saying a field is 'required', or by giving the type of the field, rather than using the extensive scripting that was necessary in traditional HTML forms. This means that the user experience is greatly improved, since the browser can always warn the user of any incorrectly filled fields before the form is submitted."

XML is at the core of the XForms model, and delivers key advantages to the XForms technology:

• Data received from an XForm is already strongly typed, well-formed, easy to validate, and process -- in other words, it is XML.
• Using XML 1.0 for the description of results -- called 'instance data' -- ensures that the submitted data may be easily internationalized.
• XForms may be used to 'edit' any XML document.
• Existing XML schemas from business processes may easily be used for the validation of instance data.
• XML schemas may be reused across XForms, helping keep sets of forms up to date and consistent.
• XForms can talk to Web services, finally integrating the user into the Web services process.

Moreover, XForms, while initially designed to be integrated into XHTML, may be adopted by any suitable markup language, such as Scalable Vector Graphics (SVG). XForms uses XML Events, another W3C technology being released today, to define XML-based declarative event handlers that cover common use cases, so that the majority of XForms documents can be statically analyzed, reducing the need for complicated scripting for event handlers.

XForms Are Already Widely Implemented: "No W3C specification has been so widely implemented so early in its life cycle as XForms. Current implementations can deliver the same form to a variety of devices, including cell phones, PDAs, voice browsers, PCs, and even using instant messenger clients. Some large user communities are emerging, in particular the United Kingdom e-government interoperability framework says 'current guidance is to use the XForms 1.0 standards as defined by W3C'..."

About XForms

"Forms are an important part of the Web, and they continue to be the primary means for enabling interactive Web applications. Web applications and electronic commerce solutions have sparked the demand for better Web forms with richer interactions. XForms 1.0 is the response to this demand, and provides a new platform-independent markup language for online interaction between a person (through an XForms Processor) and another, usually remote, agent. XForms are the successor to HTML forms, and benefit from the lessons learned from HTML forms."

The primary difference when comparing XForms with HTML Forms, apart from XForms being in XML, is the separation of the data being collected from the markup of the controls collecting the individual values. By doing this, it not only makes XForms more tractable by making it clear what is being submitted where, it also eases reuse of forms, since the underlying essential part of a Form is no longer irretrievably bound to the page it is used in.

A second major difference is that XForms, while designed to be integrated into XHTML, is no longer restricted only to be a part of that language, but may be integrated into any suitable markup language. XForms has striven to improve authoring, reuse, internationalization, accessibility, usability, and device independence.

XForms, in contrast to HTML forms, are comprised of separate sections that describe what the form does, and how the form looks. This allows for flexible presentation options, including classic XHTML forms, to be attached to an XML form definition.

The XForms User Interface provides a standard set of visual controls that are targeted toward replacing today's XHTML form controls. These form controls are directly usable inside XHTML and other XML documents, like SVG. Other groups, such as the Voice Browser Working Group, may also independently develop user interface components for XForms.

An important concept in XForms is that forms collect data, which is expressed as XML instance data. Among other duties, the XForms Model describes the structure of the instance data. This is important, since like XML, forms represent a structured interchange of data. Workflow, auto-fill, and pre-fill form applications are supported through the use of instance data.

Finally, there needs to be a channel for instance data to flow to and from the XForms Processor. For this, the XForms Submit Protocol defines how XForms send and receive data, including the ability to suspend and resume the completion of a form..." [adapted from the Spec and XForms home page]

About XML Events

The new W3C Recommendation XML Events: An Events Syntax for XML has been produced by the W3C HTML Working Group as part of the HTML Activity. "A test suite for XML Events has been developed as part of a public XForms 1.0 Test Suite, along with an implementation report.

As presented in the Recommendation's Introduction, an "event is the representation of some asynchronous occurrence (such as a mouse click on the presentation of the element, or an arithmetical error in the value of an attribute of the element, or any of unthinkably many other possibilities) that gets associated with an element (targeted at it) in an XML document."

"In the DOM model of events, the general behavior is that when an event occurs it is dispatched by passing it down the document tree in a phase called capture to the element where the event occurred (called its target), where it then may be passed back up the tree again in the phase called bubbling. In general an event can be responded to at any element in the path (an observer) in either phase by causing an action, and/or by stopping the event, and/or by cancelling the default action for the event..."

"An action is some way of responding to an event; a handler is some specification for such an action, for instance using scripting or some other method. A listener is a binding of such a handler to an event targeting some element in a document."

"HTML binds events to an element by encoding the event name in an attribute name, such that the value of the attribute is the action for that event at that element. This method has two main disadvantages: firstly it hardwires the events into the language, so that to add a new event, you have to make a change to the language, and secondly it forces you to mix the content of the document with the specifications of the scripting and event handling, rather than allowing you to separate them out. SVG uses a similar method..."

"The process of defining a new version of HTML identified the need for an extensible event specification method. The design requirements were to: (1) syntactically expose the DOM event model to an XML document; (2) provide for new event types without requiring modification to the DOM or the DTD; (3) allow for integration with other XML languages..."

The XML Events Module provides for support of the listener element. The element listener and its attributes defined in the XML Events specification are the method of binding a DOM level 2 event at an element to an event handler. They encapsulate various aspects of the DOM level 2 event interface, thereby providing markup-level specification of the actions to be taken during the various phases of event propagation..."