Interactive Web Services with XForms

January 16, 2002

A form -- whether a sheet of paper or a web page -- represents a structured exchange of data. Web services, as typified by emerging standards like SOAP, WSDL, and UDDI, is an excellent approach to exchanging data in a structured way, although usually the exchange is between machines. Since computers are much better at, well, computing, web services is an important and overdue development in the evolution of the Web. Nevertheless, web services applications exchanging information only between machines isn't very interesting: lots of electronically accessible information originates with ordinary human beings.

People Can Be Web Services Too

WSDL talks about transmission primitives between endpoints defined for Web Services, including

Request-response (The endpoint receives a message, and sends a correlated message)
Solicit-response (The endpoint sends a message, and receives a correlated message)

It's not hard to imagine either of these scenarios applying to an "endpoint" constituted by a person using a networked device. Such a point of view is attractive since it simplifies the creation of web applications that contain the necessary semantic hints to be equally valuable to people or machines. For this concept to gain widespread acceptance, however, a better method is needed to combine forms and XML across a wide variety of devices, including alternate accessibility modalities (such as audio browsers), and to do so in a streamlined way that fits well with XML and Schema-based back ends.

XForms provides this critical link between people and interactive web forms, enabling the best of both worlds: a Web populated with resources which are accessible to humans and machines.

Connecting Forms and Web Services

Technology can't really change one central fact: people (seem to) dislike filling out forms. Particularly offensive are forms that waste one's time by asking for redundant information. A frequent visitor to an online store rightly expects that some of the data they've entered previously will be "pre-filled". And yet this is surprisingly awkward to accomplish with web forms today, including the forms modules defined in Modularization of XHTML.

Imagine the following scenario. An interactive Web Service collects data from users, including user names. When the time comes to collect a payment from a particular user, he or she is prompted with a pre-filled form. Using the various form controls defined in XHTML, pre-fill is typically accomplished through either dynamic assembly or post-facto search-and-replace techniques. In the following table, bold (and red) text highlights the portion of the code that initializes the form control.

XHTML form control	Necessary code for initial value
Small amounts of text	`<input type="text" value="###"/>` To initialize: insert a `value` attribute
Large amounts of text	`<textarea>###</textarea>` To initialize: insert text content
Yes/No choices ¹	`<input type="check" checked="checked" value="foo"/>` To initialize: insert a `checked` attribute if initially checked
Multiple choice (radio button style)¹	`<input type="radio" checked="checked" value="foo"/>...` To initialize: find the `input` element with the desired `value` and insert a `checked` attribute
Multiple choice (list style) ²	`<select><option selected="selected">...</select>` To initialize: find the `option` child element(s) with the desired `value`(s) and insert a `selected` attribute

¹ In common usage, radio buttons and check boxes may have multiple form controls with the same name. To correctly initialize these, it is necessary to examine the entire document to see if there are duplicated names and set the checked attribute on the proper form control (or controls).

² Initializing select form controls is similarly difficult, although even harder since multiple selection may or may not be possible (depending on the multiple attribute), and since each option element can either have a value attribute or default to the element content.

In short, every flavor of XHTML form control requires special-case coding to initialize. This hinders interoperability and requires extra effort and expense when integrating forms with web services.

On the next page we'll see how this situation improves if you use XForms.

Using XForms processing, every form control is initialized consistently by specifying a piece of XML, the "initial instance data". This form data can be specified inline in the form or alternatively loaded from a remote source.

For example, this XML fragment represents credit card information as might be provided from a Web Service. Typically a Web Service would have access to an XML Schema (Schema) for such instance data, as well as deliver such information upon request (initial instance data). The element names, including namespaces, are provided by the form author: The nil elements represent data that is not currently known to the Web Service.

<i:CCInfo xmlns:i="http://www.example.com/ns"

      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <i:FullName>Micah J. Dubinko</i:FullName>

  <i:CardType xsi:nil="true"/>

  <i:Number   xsi:nil="true"/>

  <i:Exp      xsi:nil="true"/>

</i:CCInfo>

Using XForms, this data can be mapped to initial values in form controls, as well as filled in and sent back to the Web Service. To keep the example short, data for only a single form control is pre-filled here, but the principle applies identically when most or all of the form data is initially populated.

XForms in Two Easy Steps

Form authoring can be thought of as a two step process: first, create the underlying form definition, called the "XForms Model"; second, create the user interface mapped the the XForms Model. A huge benefit of this design is that existing XML and Schema resources can be directly used with forms.

Step one is to create the XForms Model. In an XHTML containing document, this goes in the head section:

<xforms:model>

  <xforms:instance xlink:href="http://www.example.com/getInstance"/>

  <xforms:schema xlink:href="CCInfo-Schema.xsd"/>

  <xforms:submitInfo action="http://www.example.com/submitInstance"/>

</xforms:model>

As short as this is, it defines a complete form, though without any means for user interaction (that's the next step). The XForms Processor looks at the initial instance data and constraints found in the XML Schema to initialize the XForms Model. A submitInfo section gives directions (all defaulted here) for writing out the submitted instance data and then where to submit it.

Step two is to attach a user interface, keeping in mind the range of possible target devices (desktop browsers, cell phones, voice browsers, paper, and so on). In an XHTML containing document, this goes in the body section:

<xforms:output ref="i:FullName"/>



<xforms:selectOne ref="i:CardType" selectUI="radioGroup">

  <xforms:caption>Card Type</xforms:caption>

  <xforms:choices>

    <xforms:item>

      <xforms:caption>MasterCard</xform:caption>

      <xforms:value>MC</xforms:value>

    </xforms:item>

    <xforms:item>

      <xforms:caption>Visa</xforms:caption>

      <xforms:value>V</xforms:value>

    </xforms:item>

  </xforms:choices>

</xforms:selectOne>



<xforms:secret ref="i:Number">

  <xforms:caption>Card Number</xforms:caption>

</xforms:secret>



<xforms:input ref="i:Exp">

  <xforms:caption>Expiration Date</xforms:caption>

</xforms:input>

(Complete XHTML+XForms document)

Here there are four form controls defined:

An <output> form control to display (but disallow changing) the User's full name.
A <selectOne> form control to choose the card type from a list. A user interface hint is included to treat it like a radio button group.
A <secret> form control (bound to an xsd:decimal datatype from the Schema) to allow the entry of a credit card number without rendering the digits as they are typed.
An <input> form control (bound to an xsd:gYearMonth from the Schema) to allow the entry of the expiration date.

The ref attributes on each form control, which contain XPath location paths, serve as a connection between the form controls and a data location in the instance data.

Compared to the XHTML discussed earlier, getting XML data in and out of forms is cleaner and simpler. And a new set of form controls provides greater functionality across a wider set of devices of all shapes and sizes. Form building is generally an iterative process. From this foundation, additional constraints, validations, and usability enhancements can be added.

Conclusion

Since its inception the Web developed as a rich source of information trapped in a format meant primarily for human consumption. This led to a raft of retyping, screen-scraping, and poorly integrated applications. Recently, the focus has shifted towards automatically discoverable, self-describing modular applications. XForms technology is the bridge between these two worlds.

Authoring XForms is simple, taking only two steps, and you can reuse Schemas and instance data already available in a web services environment.

The main issue at this point is the lack of conforming XForms Processors with which to utilize forms on the client side. The XForms specification is still a moving target, still in the "Working Draft" phase. The XForms Working Group is actively seeking feedback and implementation experience. In the short term, server-side tools that transform XForms into browser-digestable HTML are a good solution. Looking farther out, next-generation networked devices are lining up support for XForms. Who knows, maybe even someday browsers will support XForms.

In the end, information for, from, and about people is what's interesting. New tools on the horizon make this easier than ever.