Interactive Web Services with XForms
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.
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)
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.
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.
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||
To initialize: insert a
|Large amounts of text||
To initialize: insert text content
|Yes/No choices 1||
To initialize: insert a
|Multiple choice (radio button style)1||
To initialize: find the
|Multiple choice (list style) 2||
To initialize: find the
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).
form controls is similarly difficult, although even harder since multiple
selection may or may not be possible (depending on the
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.
Pages: 1, 2