XHTML Extended Forms Play Pen

This page is the playpen for work on XHTML Extended Forms and will be used to provide links to work in progress, and other materials.

Sketches provided by participants

This section is intended to list sketches of ideas provided by participants as an aid to discussions. Please mail the W3C staff contact Dave Raggett if you would like to add a sketch to this section. Come on, don't be shy!

Here is a link to a talk on XForms presented by Dave Raggett to the Munich F2F of the HTML working group. It gives an personal interpretation of how XForms relates to XML Schemas.

Sample Form

It would seem like a good idea to try out our ideas for XForms on a reasonably complex example. The starting point is an working implementation in HTML and ECMAScript that demonstrates the functionality. We could then demonstrate alternative representations in XML, compiling them to HTML+script code, and see how well the different approaches stack up against each other.

To set this in motion, Dave Raggett is working on an order form involving, customer details, one or more line items, payment details and a summary report. Here is a link to a sample order form. It works best in IE where the table of line items smoothly expands as needed, and the total, tax and shipping fields are dynamically updated as new line items are added. Pressing the submit button invokes checks on missing fields, and if all is well, you will see a pop-up window showing how the form's data would be encoded in XML. A cross-browser version is planned.

Dave Raggett has provided his idea of how this could be represented declaratively in XML, avoiding the need for the complex ECMAScript code in the HTML representation. Dave's representation is based strongly on the layering ideas he describes in the presentation linked above. It is still at an early stage and currently lacks the detailed form logic described in the comments.

Gavin McKenzie has provided an XFA implementation of the sample form. Note that this models an earlier version of the form where the payment details were placed near the start of the form.

Sebastian Schnitzenbaumer has provided an FML implementation of the form, and you can try a live demo of this implemented in Mozquito.

Data modelling for Forms

XForms calls for a separation of the form's data from its user interface. The approach involves providing an explicit data model for the form. Here is one proposal for how the data model could be represented (revised 14th Feb 2000).

User Interface for XForms

Dave Raggett is working on a preliminary analysis for the user interface requirements and some ways for implementing these. The binding from the UI to the data model will use the model-view-controller paradigm, and will allow different UIs to use the same data model and back-end. Here is the first cut, which sets the scope and analyses the presentation used in a printer properties dialog. Further work is planned for examples of paper forms, and for the PalmOS.

Style sheets and Forms

The CSS working group is interested in style properties for forms. It aims to offers authors the means to control the appearence of form elements, the means to bind combinations of keys to fields and the ability to allow the tab key to do something other than the default when navigating form elements.

User Interface and Forms Enhancements (Proposal)

The following ranks general forms requirements requested by users over a period of several years. Contributed by Paula Klante of Jetform

Forms Functionality:

Low:

Tabbing control between data entry fields
Improved GUI controls (choice lists, checkboxes, radio buttons, action buttons, bar codes, etc.)
Date formatting
Currency formatting
Patterns for field data display (i.e. picture clauses for text and numeric data fields)
Mandatory fields detection and enforcement
Context sensitive field help
Protected fields (i.e. display only for calculated fields or locked by signature fields)

Medium:

Field Calculations (including date and time, basic arithmetic, and financial calculations)
Data Validations
Data controls
Database lookups and updates.

High:

Digital signatures.
High fidelity printing (Many highly regulated industries such as government and financial require precise and exact print output.)
Saving work in progress and completing the form during another session.
Multiple page forms with data validations and calculations across the pages.
Spell checkers.
Dynamic subforms (i.e. the number of dependents entered would generate at run time the number of dependent subforms that would be displayed.)

Accessibility and Platform Independence

As people start to access the Web from new kinds of platforms, it will be important to be able to interact with forms using devices with widely varying capabilities. On desktop systems with high resolution displays, viewed from close up, it is practical to view lots of information in a rich layout. A simpler presentation is needed on Web-enhanced television sets and on smaller devices such as hand-held communicators. Voice browsers will allow you to browse and fill-in forms without using your eyes at all.

The implication is that forms need to be represented in a way that allows a standard logical model to used, independent of the way the form is presented on any given platform. This will facilitate tools that transform Web pages for different device capabilities.

Richer Layout of Forms

In 1999, designers are still heavily reliant on HTML tables for laying out forms. One problem arises from the way form fields are required to be contained within a form element as this makes it hard to spread the form across several table cells. This is motivating a change whereby fields could explicitly reference a form element without the need to be contained within it.

Style sheets and scalable vector graphics promise to make it easier to control the layout of form fields, but is there a need for a further layout mechanism? For instance, a constraint-based layout mechanism that allows you to progressively divide the page up vertically or horizontally. Other ideas relate to the ability to break up a form into a set of smaller parts which can be viewed and filled out one at a time. This begs the question of whether you could preserve local state across several pages. A notion of session state seems appropriate and would also help with convergence plans for WML and HTML.

Additional Material

XHTML Forms 1.0 Requirements: Prepared by Sebastian Schnitzenbaumer and Malte Wedel, and later revised by Dave Raggett. This draft is planned to be released a public working draft, after review by the HTML working group as a whole.
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.
Forms Markup Language (FML) 0.8: 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. FML merges web application authoring in HTML/JavaScript/CSS into a simple but powerful markup language.
Extensible Forms Description Language (XFDL) 4.0: 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.
JetForm's XML Forms Architecture: JetForm have defined an XML based forms language which covers both presentation and structure. The specification is in two parts: XFA-FormCalc which defines a simple scripting mechanism and XFA-Template which defines the markup language for forms.; Jetform have also made available internal specifications for data formats for Dates/Times, and for Money.
Xerox proposal for a cross media forms language, Zipped files (18Kb).: Describes a small XML-based forms specification language used for form templates and for filled forms. The proposal is designed to be a medium-neutral forms definition language. The same definition should be renderable on visual browsers, voice browsers, paper, etc.
Formsheets and the XML Forms Language: Paper by Anders Kristensen (HPLabs) describing 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
User Agent Authentication Form Elements: 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.
Form-based Device Input and Upload in HTML: 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.
ECML, see also NOTE-P3P-ecom (now an acknowledged submission to W3C): ECML is a markup language for credit card payment information, ship-to and bill-to addresses. It specifies these as a set of named fields with minimum widths and encodings, e.g. 2 letters abbreviations for US States in accordance with the US Postal standards. ECML is being proposed as an extension of W3C's P3P. The idea being to save user's from the need to re-enter the same information each time they want to place an order.
SOAP: Simple Object Access Protocol
: SOAP defines an RPC mechanism using XML for client-server interaction across a network with HTTP as the base transport, and XML documents as the means for encoding requests and responses. See also the archives of SOAP@discuss.develop.com, the mailing list for discussions on the SOAP proposals.