This chapter is informative.
The design of existing Web forms didn't separate the purpose from the presentation of a form. XForms, in contrast, 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 following illustrates how a single device-independent XML form definition, called the XForms Model, has the capability to work with a variety of standard or proprietary user interfaces:
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, are independently developing 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.
The following illustration summarizes the main aspects of XForms:
The following sections will explain these in greater detail.
The XForms Model is the non-visual definition of an XML form. It serves several purposes:
The XForms Model is subdivided into two components: Data Structures and XForms Extensions.
![The XForms Model:
A dotted line surrounds two boxes labeled [Data Structures] and [XForms Extensions].
The Data Structures box contains Structure and Types. The XForms Extensions
box contains Constraints, Dependencies, Expressions, and Calculations](http://www.w3.org/TR/2000/WD-xforms-20001219/images/arch3.jpg)
The Data Structures Component provides a schema that describes the instance data and provides reusable data types, a role that fits well with XML Schemas. Due to this, the XForms Working Group is focusing on an XML Schema compatible definition for the Data Structures Component. In addition, we are investigating the option of a simpler syntax, more in tune with current XHTML authors.
Additionally, the XForms Model includes aspects that are not typically expressed in schemas, like additional constraints, dependencies, an Dynamic Constraints Language, and calculations. For instance, stating that a model item is "read only" is outside the scope of XML Schema, yet clearly an important capability for an XML form definition. XForms Extensions Components such as these will be handled through attributes that will extend the XML Schema syntax.
The XForms Model is capable of representing potentially complex interrelationships between model items. One example of this might be a "spouse information" section that is only applicable when the user has previously indicated that he or she has a spouse. Relationships such as these, along with calculations, will be represented in a lightweight, XML-friendly Dynamic Constraints Language.
The XForms Model will also keep track of numeric values using decimal arithmetic. Unlike "floating point" math which is unable to exactly represent certain commonly-used values, decimal arithmetic works with numbers in the way most users expect, and avoids many types of rounding errors.
Lastly, the XForms Model is closely related to the XML instance data. The definition of the XForms Model provides an area with an open content model where arbitrary well-formed instance data in any namespace can reside. XForms authors are typically not required to include instance data, although they are free to do so. Some useful applications of instance data include:
The user interface is the part of electronic forms most immediately noticeable to users. By separating the user interface from the rest of the form, XForms provides flexibility in presentation options. In order to provide increased functionality, a separate XForms User Interface will be specified. This will include all the functionality of current XHTML forms, and more.
Typically, XHTML form controls are
expressed in fairly generic terms, for instance <select>
to represent menu controls. Web application designers have expressed a desire
for more control over presentation. XForms enable this additional level of control,
since presentations specific to desktop browsers, handheld devices, and even
paper can be attached to a single XForms
Model. This modular construction also leads to alternate user interfaces.
In particular, the Voice Browser Working Group is interested in developing a
specification for non-visual form controls
for use with XForms.
XForms User Interface consists of a set of XHTML modularization elements used to define user interface widgets (form controls) and a binding mechanism for connecting these form controls to the underlying XForms Model. Even though the XForms form controls are designed for use with XHTML, we do not mandate a complete XHTML rendering engine for displaying XForms User Interfaces. Specifically, the intent is for XForms User Interface to be rendered without the need to implement a full table rendering model as required today by HTML 4.0.
The XForms form controls are designed for use with XHTML and are initially inspired by the set of form controls available in HTML 4.0 as well as common constructs in use today that require the use of scripting --rather than declarative markup. The intent is for these new set of XForms form controls to be used within XHTML documents to provide a rich end-user experience while using declarative markup.
The final necessary component of XForms is "binding", which in this case refers to making the connection between the XForms Model and XForms User Interface. The XForms Working Group will define a binding for XHTML form controls and XForms User Interface form controls. The binding mechanism is designed to be generic and device-independent i.e., it is intended that this mechanism be usable for binding a multiplicity of user interfaces suitable for use on different devices to the same underlying XForms Model. Other groups that define XForms presentations may define corresponding bindings.
Conventional XHTML forms send instance data over HTTP, in flat name/value pairs, with unsophisticated URL-encoding. Later, the ability to include multipart mime-encoded data was added to support file upload. XForms are designed from the ground up to allow rich, internationalized, hierarchical XML instance data, transferred over the XForms Submit Protocol.
Besides just submitting data, XForms have the additional requirement of suspending a form-filling session, later resuming it. This also calls for another use for the XForms Submit Protocol--a way to remotely serialize the instance data.
As of this writing, an XML Protocol Working Group has been formed within the W3C, and is currently accepting requirements. The XForms Working Group will work closely with this effort to ensure that the end results will be compatible with the XForms Submit Protocol.