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.
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.
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
necessary to examine the entire document to see if there are duplicated names and
checked attribute on the proper form control (or controls).
select form controls is
similarly difficult, although even harder since multiple selection may or may not
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.
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
<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
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
<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>
Here there are four form controls defined:
<output>form control to display (but disallow changing) the User's full name.
<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.
<secret>form control (bound to an
xsd:decimaldatatype from the Schema) to allow the entry of a credit card number without rendering the digits as they are typed.
<input>form control (bound to an
xsd:gYearMonthfrom the Schema) to allow the entry of the expiration date.
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
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.
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.