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
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.
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
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
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
The following ranks general forms requirements requested by users over a
period of several years. Contributed by Paula Klante of Jetform
- 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)
- Field Calculations (including date and time, basic arithmetic, and
- Data Validations
- Data controls
- Database lookups and updates.
- Digital signatures.
- High fidelity printing (Many highly regulated industries such as
government and financial require precise and exact print
- Saving work in progress and completing the form during another
- Multiple page forms with data validations and calculations across
- Spell checkers.
- Dynamic subforms (i.e. the number of dependents entered would
generate at run time the number of dependent subforms that would be
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
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
- XHTML Forms 1.0
- 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
- Forms Markup Language
- 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
- 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
- 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.
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
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.
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
- 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