XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.


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)

What are XForms?

As I discussed in a previous article, XForms are the new W3C technology to bring webforms and XML together. The XForms standard is based on a design which separates the user interface from the XML form definition and data. This article is based on the published 7 December 2001 Working Draft of XForms.

Comment on this article Got ideas or experience with adding user interfaces to web services, or comments on XForms? Share them in our forum.
Post your comments

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


To initialize: insert text content

Yes/No choices 1

<input type="check" checked="checked" value="foo"/>

To initialize: insert a checked attribute if initially checked

Multiple choice (radio button style)1

<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) 2

<select><option selected="selected">...</select>

To initialize: find the option child element(s) with the desired value(s) and insert a selected attribute

Related Reading


By Doug Tidwell

1 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).

2 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"
  <i:FullName>Micah J. Dubinko</i:FullName>
  <i:CardType xsi:nil="true"/>
  <i:Number   xsi:nil="true"/>
  <i:Exp      xsi:nil="true"/>

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.

Pages: 1, 2

Next Pagearrow