Introduction to XForms

Background Briefing on XForms-Schema Integration, part 1

(4 April 2001 Version)


Abstract

On 2 Apr 2001, the XForms Working Group decided to release the following information as background material to help us gather important feedback on our approach toward integrating with XML Schema. The material here includes decisions made at the recent Boston face-to-face meeting, and thus is more up to date than the published 16 Feb 2001 XForms Working Draft.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document.

This document has no official W3C status.

Public comment on this document is welcome on the XForms mailing list <www-forms@w3.org>. To subscribe, send an email to <www-forms-request@w3.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.

Members of the XML Schema and XForms Working Groups may wish to use the w3c-forms-schema mailing list (Members only).


1 Authoring Perspective

XForms is a reusable tagset, but at least initially, the main use of it will be within XHTML documents. XForms allows authors to work at the level of complexity vs. functionality of their choosing. At the simplest level, all that is required to start authoring XForms is a few new tags added to your HTML page. XForms will by default submit the data in the same format as XHTML forms would have -- urlencoded name/value pairs.

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xform="http://www.w3.org/2001/02/xforms">
  <head>
    <title>example 1</title>
    <xform:xform/>
  </head>
  
  <body>
    <xform:someWidget ref="firstname">
      <xform:caption>First Name</xform:caption>
    </xform:someWidget>

    <xform:submitWidget/>
  </body>
</html>

The two important things in this example are:

  1. An <xform> element in the head section tells us that this XHTML uses XForms.
  2. Various new user interface gadgets defined in XForms (here represented by <someWidget> and <submitWidget>) are added to the body.

This design allows today's HTML authors to easily migrate from XHTML forms to XForms.

With a few additional changes, Web forms can use the full power of XML. To get the benefit of XML data submission, you need to provide an example of what your XML looks like. XForms provides a special element, <instance> that serves as a container for prototypical instance data. By default, the following will submit XML instance data, based on the XML that appears inside the <instance> element:

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xform="http://www.w3.org/2001/02/xforms">
  <head>
    <title>example 1</title>
    <xform:xform>
      <xform:instance xmlns="http://example.org/ns">
        <root>
          <child attr="value"/>
        </root>
      </xform:instance>
    </xform:xform>
  </head>
   ...

Note that the contents of <instance> come from another namespace. Submitted data might look something like this:

<root xmlns="http://example.org/Ns">
  <child attr="Micah"/>
</root>

When values are entered into any given form control, what part of the instance data gets updated? To specify this, XForms defines a specific connection, called binding, which is expressed through binding expressions. Binding Expressions are based on XPath notation. For instance, to map to the value of the "attr" attribute above, the binding expression would be /root/child/@attr. The remainder of the example above would look like this:

...
  <body>
    <xform:someWidget ref="/root/child/@attr">
      <xform:caption>First Name</xform:caption>
    </xform:someWidget>

    <xform:submitWidget/>
  </body>
</html>

This demonstrates how user interface form controls point back to the instance data.

1.1 Where to go from here...

So far, none of these examples have specified an explicit XForms Model, which provides to richest forms features (validation, calculations, and dependencies, to name a few) but is also the most complex. This section describes the latest thinking of the XForms Working Group, including alternatives where they exist.

The foundation of the XForms Model is the datatyping processing defined in XML Schema Part 2 - Datatypes. In addition to a number of built-in datatypes, this specification defines ways to create new datatypes (through restriction, union, or list) and in-fact defines several derived datatypes. XForms is expected to use most or all of these datatypes in various conformance profiles (see Appendix for details on conformance).

To get a feel for how this might look, consider the following fragments:

<xsd:restriction base="xsd:string">
  <xsd:pattern value="\d{3}-\d{4}"/>
</xsd:restriction>

or perhaps an attribute-based syntax:

xform:type="xsd:string" xform:pattern="\d{3}-\d{4}" ...

These define a new (anonymous) datatype based on the Schema string datatype, and further constrains the allowable values through a regular expression. In addition to constraining facets, XForms-based properties, such as required and calculation can be included with the datatype reference. This combination of datatype information and form-specific properties is called a model item in XForms terminology, one member of an XForms Model.

There are two main schools of thought on the relationship between model items and instance data:

  1. An XForms Model should define the instance data
  2. An XForms Model should point to the instance data

Position 1 evokes the design process for a needed piece of XML -- defining how the XML should look by authoring a Schema, in this case including all the necessary forms properties. Authoring a form and authoring a Schema go together. This position tends toward a subset involving both Schema-1 and Schema-2.

Position 2 maintains that the instance data is already there (in the <instance> element), and doesn't need to be defined again. Form controls use an XML path representation (ref="/root/child/@attr" above), where an element based syntax would be inconvenient. The same logic applies to model items. This position tends toward a subset of Schema-2 only.

Both positions have merit, and can be well-argued by various members. We welcome outside input, particularly from those knowledgeable in Schemas, to help us make the best decision.

Appendix: Conformance Profiles

XForms is being designed for use on hardware platforms of all sizes, from tiny handheld devices to high-powered servers. Clearly, a one-size-fits-all approach has its drawbacks. For this reason, the XForms Working Group has begun specifying two conformance levels for XForms Processors, documents, and authoring tools.

XForms Basic

This conformance level will be suitable for devices with limited computing power, such as mobile phones, handheld computers, and appliances. This conformance level will depend on a subset of XML Schema, and will not include any resource-intensive features, such as IEEE floating point libraries.

As we define how Schema integrates, we are focusing first on XForms Basic. This is the primary driver for the need to subset XML Schema in the first place.

XForms Full

This conformance level will be suitable for more powerful forms processing, such as might be found on a standard desktop browser or a server. This conformance level should utilize all of XML Schema, if possible.

References

XML Schema Part 1 - Structures

XML Schema Part 2 - Datatypes

XForms Requirements

XForms 1.0