First published in Library Hi Tech, column, vol 21, no 3, pp 367-381, 2003.
Web forms: The Next Generation
AUTHOR
Dr Judith Wusteman is based at the Department of
Library and Information Studies at University
College Dublin, Ireland. judith.wusteman@ucd.ie http://www.ucd.ie/~lis/staff/wusteman/index.html
PROFESSIONAL BIOGRAPHY
Judith Wusteman joined the staff of the Department of Library and Information Studies at University
College Dublin in September 1997. Prior to this, she spent seven years as a lecturer in computer science at the University of Kent at Canterbury. Her research interests are in electronic publishing, specifically
XML and digital libraries, ejournals, document structure and text encoding. She has been involved in various electronic library projects and has provided
SGML and XML consultancy for ejournal, encyclopedia and digital library systems.
KEYWORDS
XForms, XML, WWW
ABSTRACT
XForms are the future of data entry on the Web
[1]. Their advancement to W3C Candidate
Recommendation status in November 2002 has been followed by a variety of implementations [2,3].
Although they are not yet natively supported by the major browsers, it is becoming increasingly obvious that they will be a central component of the Web.
This column describes a simple digital library application of XForms that illustrates their superiority over the current generation of HTML forms.
WHAT'S WRONG WITH WEB FORMS?
XHTML 2.0 introduces major changes to HTML as we know it [4]. Some changes that may cause temporary disorientation are the disappearance of the img and br tags. More significantly, Web forms are at last to be updated.
Forms support in HTML has existed in its current guise for a decade, that is, since the early days of the
Web. It is one of the few Web technologies not to have changed to any great extent in that time. The current generation of Web forms, which I will refer to as "HTML forms", was never a completely satisfactory solution to user data input. And, with the huge advances in other Web technologies, particularly at the server end, HTML forms are really showing their age.
One of the main problems with HTML forms is their reliance on scripting, particularly as the implementation of the latter varies so greatly between browsers. Because of this and other inconsistencies between browser implementations of forms, most forms processing occurs at the server. This can mean unnecessary traffic between client and server and a potentially heavy load on the latter. Even simple data validations and calculations on form fields require a round trip to the server.
In addition, the lack of distinction between the data to be submitted, the logic that controls that data and the presentation of the form itself leads to devicedependence. It is difficult to see how any distinct component of a conventional form designed for display via a desktop computer could be used by a voice browser or a handheld computer, or for paper delivery. This lack of distinction also complicates the separation of duties between the Web designer, responsible for the look and feel of the site, and the developer responsible for data validation. HTML
Forms are also handicapped by their limited set of
GUI (Graphical User Interface) controls; drop-down combo-boxes, slider and calendar controls, for example, are not available.
As well as all these limitations, HTML forms suffer from poor integration with the emerging XMLbased Web; not at all surprising as they predated
XML by five years.
XFORMS
The next generation of forms for the Web is, of course, an XML application. Its development began as part of the W3C HTML activity but it now has its own dedicated working group [5]. The XForms standard is currently at Candidate Recommendation stage; this means that a final W3C standard could be published in 2003. The term XForms does not have a singular; just like the words clothes and scissors, it is always plural.
XForms is not designed as a standalone specification; initially developed to be integrated with XHTML, it can also be embedded within other
XML markup languages including Scalable Vector
Graphics (SVG) and Wireless Markup Language
(WML). One of the great strengths of XForms is its reliance on existing XML standards. As Micah
Dubinko (14 Apr 2003), an editor and author of
XForms, comments:
XForms has little, if any, "new science". It's all about helping people find a better way than the reams of unmaintainable JavaScript and Perl scripts currently in use.
TRYING IT OUT
To illustrate the considerable advantages of
XForms, we will look at a simple XForms interface for depositing items in a fictional digital library. All relevant files are available online [6] and the major ones are also listed in appendices A, B and C. The example has been designed to run on XSmiles [7], the only fully-fledged browser that already natively
1

First published in Library Hi Tech, column, vol 21, no 3, pp 367-381, 2003. supports XForms. This "open XML browser for exotic devices" is easy to install and also supports other interesting XML standards such as XSL-FO,
SMIL and SVG. As of June 2003, the current version is 0.8.
It could almost be said that the sophistication of forms using the XForms standard is limited only by the designer's imagination. There are already some very complex examples out there [3,8]. But the aim of the example discussed here is to illustrate that reasonable results can be gained from quite simple markup. The XForms standard relies on several other
XML family standards, namely XML Schema [9],
XML Events [10] and XPath [11]. However this example is sufficiently simple for their use to be largely intuitive. A central aim of XForms is ease of use and the following form is certainly more intuitive than the reams of scripting it replaces.
FIGURE 1 : Files involved in the XForms example
The Files
As can be seen in Figure 1, the input files for our example comprise an XHTML file (xforms.xml), two
XML schemas (resource.xsd and dc.xsd) and a CSS stylesheet (xforms.css). The form is contained within the XHTML file. The data collected by XForms is expressed in XML. By defining the structure and content of this data, the schemas enable its client-side validation. Our example requires reference to not one but two schemas because I have mixed Dublin Core elements [12] with elements of my own invention in the data. resource.xsd describes the overall structure of the data file and references dc.xsd. The latter describes the Dublin Core elements I have used.
Without the schemas, the form still works but validation is skipped. The CSS stylesheet is optional and simply improves the form's presentation.
XSmiles supports a smaller subset of CSS than the latest versions of Microsoft Internet Explorer and
Mozilla so the form looks different when viewed via these three browsers.
If you want to try running this form yourself, you should open the XHTML file from within the
XSmiles browser. The form should appear as shown in Figure 2.
FIGURE 2: The example form as displayed in
XSmiles
THE DETAILS
Unlike HTML Forms, XForms allows authors to separate the data, the logic that controls this data and how the form, and data are presented to the user.
XForms comprise three major sections: the model, the form controls and the event handlers. The data is controlled by the model and the presentation by the forms controls. The logic is controlled by events and validation rules. In other words, XForms supports the
2 widely used model-view-controller (MVC) model of user interfaces [13].
FIGURE 3 : The example XForms model
THE MODEL
The XML data collected by XForms is referred to as the instance data and may comprise data entered by the user as well as data calculated by the form and predefined data. The structure of this instance data is described by the instance element that occurs within the model element. The instance data need not be supplied inline with the form; a pointer to its location can be included in the model instead.
Within an XHTML context, the model element is defined in the head of the XHTML document. As shown in Figure 3, model has just two sub-elements in our example: submission and instance . The former has a similar though potentially more sophisticated function to <input type="submit"> in HTML forms.
The elements dc:date and message have been prefilled with the values 2003-05-05 and Depositor authorized respectively. What will be submitted to the server after processing of the form is everything contained within the instance element, that is, an
XML document with the root element entry . The
XML document will be instantiated with values as detailed in Figure 3, except for any values changed by the interaction with the user. Comparing this structured and human-readable format with the unstructured data-value pairs submitted by an HTML form highlights one of the many advantages of
XForms. As there is no in-built structure to an HTML form, considerable effort must be put into creating proprietary naming conventions to compensate. For example, to encode just the depositor name and id for submission to the server, an HTML form might produce code as follows: entry.metadata.depositor.name=Judith%20Wus teman&entry.metadata.depositor.id=wust
For the server to decipher the meaning of such data can be no small task.
If you are trying out this example using the
XSmiles browser, you will find that hitting the submit button will display, on screen, the XML file that would be sent to the server in a live system.
THE FORM CONTROLS
The components of the form that deal with data entry and display are referred to as the form controls or user interface controls. They are listed within the body of the XHTML document. XForms defines a comprehensive set of device-neutral, platformindependent form controls. For each element of data defined in the model, a form control defines its appearance via the client. These controls can be

First published in Library Hi Tech, column, vol 21, no 3, pp 367-381, 2003. combined with stylesheets to provide sophisticated form displays.
Text input
Some of the controls, for example text input via input , textarea , and secret , appear very similar to those in HTML forms. Examples of these are shown in Figure 4.
FIGURE 4: Text input controls
Just as in HTML forms, the input element is used for the entry of small amounts of text and textarea for larger amounts. secret is the equivalent of the HTML form's <input type="password">.
In our example, the model and form controls are bound to one another via the ref attribute using XPath expressions. XPath is a language used to address parts of an XML document. Here, its use is similar to a path in a file system and is intuitively simple.
The hint and help elements provide a method of displaying short or longer pieces of text when the cursor is held over the relevant control. Exactly how this information is displayed depends on the client and any stylesheets applied; hence, deviceindependence is maintained. These two features are partially supported in the current version of XSmiles; the browser appears a little temperamental as to whether it displays the relevant messages or not.
Validation
The use of schema enables the form to be validated before submission. For example, within the schema resource.xsd, category is defined as a string with a value of librarian, researcher, creator or other . And password is defined as a string of between five and fifteen characters. XSmiles highlights validation errors by colouring the relevant form field pink. The password field will remain pink, for example, until a string of an acceptable length is entered. In addition, a detailed error message will appear in the status bar:
XForms validation error: cvc-patternvalid: Value 'junk' is not facet-valid with respect to pattern '\w{5,15}'
Future XForms processors will, no doubt, provide more user-friendly error messages (preferably ones that do not expose the values of secret fields!).
If the submit button is pressed before all the data is valid, the following error message is displayed:
There are errors in the form, it could not be submitted.
The user can then make the required changes before attempting submission again, thus reducing traffic and server load.
3
Selecting options
As with HTML forms, XForms enables the selection of one or more options from a pre-defined list.
The select1 form control is for selection of just one option whereas the select control enables section of one or more options. Figure 5 illustrate the use of these two controls to select one resource type
(Article, Book, Monograph or Other) and one or more resource formats (from ASCII, PDF, HTML and XML) respectively. To select more than one format within XSmiles, the control key is used, as is normal for multi-select operations in Windows.
FIGURE 5: select1 and select form controls
These controls provide another illustration of how
XForms enables device-independence. Again, unlike in HTML forms, it is up to the client to determine the appropriate mode of display for select and select1 . A voice browser, a mobile phone and a paper printout, for example, would all render the concepts differently. Both of these controls can include an optional appearance attribute, the value of which provides the client with some indication as to how to display the control. (This attribute is not fully implemented in XSmiles 0.8.) The value full indicates that all choices should be on display at all times, compact , a fixed number of choices with scrolling as needed and minimal , a minimum number with temporary rendering of other choices. But these are just a general indication of rendering that can be interpreted differently by different clients. Again, in more sophisticated examples, a stylesheet would be used to determine exactly what these options would mean for appearance.
Input of richer data-types
XForms really comes into its own when dealing with richer data-types. For example, the use of a popup calendar for date entry, as shown in Figure 6, is likely to be popular.
FIGURE 6 : The example form with a pop-up calendar activated
In this case, XForms simply defines an input form control for element date :
<xforms:input ref="/entry/metadata/dc:date">
<xforms:label>Date of completion of data collection</xforms:label>
</xforms:input>
And the Dublin Core schema just identifies date as of type xsd:date , that is, the built-in date type for XML
Schema (Vint, 2003):
<xs:element name="date" type="xs:date"/>

First published in Library Hi Tech, column, vol 21, no 3, pp 367-381, 2003.
It is the client, XSmiles, that determines that, unless the default date is accepted, a pop-up calendar will be activated.
Another useful form control is
XSmiles implements this as a button with the message Attach resource file (or zipped files) on the button face.
The upload control also accepts input from devices such as microphones, pens and scanners and even video and 3D where sufficient hardware support is available. This is one of the features of XForms that will revolutionise Web forms.
EVENT HANDLING
The third major component of XForms, namely event handlers, is most simply illustrated by considering the use of the trigger control. The latter is similar to the HTML form button and allows for user-triggered actions.
<xforms:trigger> range . This provides for selection of a value from a sequential range. One could imagine the usefulness of such a control in the submission of an article peer review, for example. The following snippet of code would define a control for entry of a value between -5 and
+5 with a step value of 0.5.
<xforms:range ref="/review/relevance" start="-5.0" end="5.0" step="0.5">
<xforms:label>Article relevance</label>
</xforms:range>
A graphical browser would be likely to render the above example as a slider, as illustrated in Figure 7, or as a rotary control.
FIGURE 7: Slider control
Outputting data
A simple but useful control for which there is no equivalent in HTML forms is output . This displays instance data inline. In Figure 6, the chosen resource formats, HTML and XML, are displayed immediately below the control for selecting these formats. This is enabled by the following code:
<xforms:output ref="/entry/metadata/dc:type"/>
Uploading data
In our example, the upload control is used to enable the uploading of a file from the local file system:
<xforms:upload ref="/entry/resourceFile">
<xforms:label>Attach resource file
(or zipped files)</xforms:label>
</xforms:upload>
<xforms:label>Check
authorisation</xforms:label>
<xforms:message ev:event="click" level="ephemeral" ref="/entry/message"/>
</xforms:trigger>
As can be seen in Figure 2, the trigger control listed above is rendered as a button with the label value Check authorisation on the button face. Again, rendering decisions are up to the client with possible contributions from a stylesheet. When the button is clicked, a message referenced by the XPath address
/entry/message is displayed. In our simple scenario, the default message is Depositor authorised . In a live system, the data would first be validated at the client and then a round trip to the server might be required to confirm authorisation. The attribute value ephemeral results in the message window disappearing after a short duration.
The XML Events standard describes the method of associating events with markup, in this case the association of the mouse click with the code stipulating the message display. XML elements, such as message , that respond to events are called actions .
The use of actions, together with XForms validation and calculation capabilities, should do away with the need for scripts. The Events standard is just one illustration of how XForms is becoming "a building block for other W3C specifications" [14] as it was specifically designed to fulfil a need identified by
XForms.
Our form provides for the scenario in which more than one creator is responsible for the digital resource being submitted. This is another example of the use of XML events and actions.
<xforms:trigger>
<xforms:label>Add creator</xforms:label>
<xforms:action ev:event="click">
<xforms:insert nodeset="/entry/metadata/dc:creator" at="1" position="after"/>
</xforms:action>
</xforms:trigger>
Again, the event in question is the clicking of a button. This time, the button has the value Add creator on its face. When it is clicked, a new node is inserted in the instance data at the point referenced by the XPath address values /entry/metadata/dc:creator , if the attributes at and position indicate that the new node should be positioned immediately after the first node.
A similar process of adding new nodes occurs for the submission of more than one keyword. (Despite working correctly in XSmiles 0.71, the insert feature does not work in version 0.8.)
ADVANTAGES OF XFORMS
4

First published in Library Hi Tech, column, vol 21, no 3, pp 367-381, 2003.
Our example has touched upon just a few of the many advantages and new features available via
XForms:

Submission to the server of structured, validated, user-comprehensible XML data.

The absence of reams of unmaintainable scripts.

Separation of data, logic and presentation, resulting in device-independence and the potential for reuse of individual components of a form.

Sophisticated GUIs, particularly support for rich data types.

Support for connections between forms and a range of input devices.

Compatibility with the emerging XML-based
Web.
Among other advances are facilities to improve internationalisation and to support multiple forms per page and multiple pages per form. There is even the facility to suspend and resume interaction with a form.
IMPLEMENTATIONS
As already mentioned, as yet, none of the major browsers natively support XForms, although it is one of the "next big tasks" in the Mozilla Roadmap [15].
But if you want to experiment now with what is likely to be a central component of the Web in coming years, you have several options.
You can install XSmiles, the only fully-fledged browser to include an XForms processor. Or you can install a stand-alone experimental system such as the
Novell XForms Technology Preview Processor [16].
This includes useful tutorial material and allows you to follow the processing of sample forms step by step.
Another approach is to try one of the several partial implementations of XForms that can be run on current browsers. FormsPlayer, an "XForms processor plug-in" [17], only functions with Internet
Explorer 6 SP 1 and requires the inclusion of some additional declarations within the form. Other applications work by mimicking the client-side processing involved in XForms through server-side mechanisms. For example, in the current version of
Chiba, an Open Source Implementation of the
XForms standard, all logic is handled at the server side; the client is solely a viewer application. Apart from this, Chiba's use of forms "largely conforms to the XForms Candidate Recommendation" [18]. A similar approach has been taken by the Apache group for the Cocoon free-ware [19] widely used in digital libraries. Cocoon's XMLForms are similar to a subset of W3C XForms, although there have been some concerns expressed about the differences between the two (Watts, 2003). In April 2003, the first version of
Chicoon, a Chiba/Cocoon integration package [20]
5 was released, thus making Chiba's XForms processing available to any Cocoon application. This appears to offer a good interim solution for Cocoon users until native XForms support arrives for the major browsers.
THE FUTURE
There is often controversy surrounding new Web standards and XForms has its share. The scenario is not exactly novel: Microsoft has announced a potentially competing specification. InfoPath 2003
[21], formerly code-named XDocs, is a forms product that will work with MS Office. There are differing views as to how the two standards relate and whether they are rivals (Udell, 2003; "W3C…", 2002). But
Dubinko (1 Apr 2003) is reassuring:
For the time being, rather than "embracing and extending", Microsoft appears to be deliberately distancing themselves from XForms, which seems to be the most comfortable position for both sides.
XForms are a good bet; any time spent learning and experimenting with them will be time well spent.
Web forms will not remain the way they are and
XForms are a well-constructed, long-overdue technology.
NOTES
[1] XForms - The Next Generation of Web Forms: http://www.w3.org/MarkUp/Forms/
[2] XForms 1.0 W3C Candidate Recommendation,
12 November 2002: http://www.w3.org/TR/xforms/
[3] W3C XForms Implementations: http://www.w3.org/MarkUp/Forms/#implementations
[4] XHTML 2.0 W3C Working Draft, 6 May 2003: http://www.w3.org/TR/xhtml2
[5] The XForms Working Group: http://www.w3.org/MarkUp/Forms/#wg
[6] Program files available at: http://www.ucd.ie/~lis/staff/wusteman/xforms/xforms
.xhtml
[7] XSmiles: http://www.xsmiles.org
[8] Novell XForms Technology Preview Tutorial: http://help.silverstream.com/help/XFormsTutorial/
[9] XML Schema: http://www.w3.org/XML/Schema
[10] XML Events: An Events Syntax for XML: W3C
Candidate Recommendation, 7 February 2003: http://www.w3.org/TR/xml-events/
[11] XML Path Language (XPath) 2.0, W3C
Working Draft, 2 May 2003: http://www.w3.org/TR/xpath20/
[12] Dublin Core Metadata Element Set, Version 1.1:
Reference Description, 6 February 2002: http://dublincore.org/documents/dces/
[13] whatis.com: model-view-controller: http://www.whatis.com/definition/0,,sid9_gci214607,
00.html

First published in Library Hi Tech, column, vol 21, no 3, pp 367-381, 2003.
[14] W3C XForms Activity Statement: What the
Future Holds: http://www.w3.org/2002/Forms/Activity.html#future
[15] XML in Mozilla: http://www.mozilla.org/newlayout/xml/
[16] Novell XForms Technology Preview Processor: http://www.novell.com/xforms
[17] FormsPlayer: http://www.formsplayer.com/
[18] Chiba: http://chiba.sourceforge.net/
[19] Apache Cocoon: http://cocoon.apache.org/2.0/
[20] "Chicoon 0.1 released", SourceForge.Net
Forums, 3 April 2003: http://sourceforge.net/forum/forum.php?forum_id=26
6049
[21] Microsoft Office InfoPath 2003: http://www.microsoft.com/office/preview/infopath/de fault.asp
REFERENCES
Dubinko, M. (1 Apr 2003), "InfoPath and XForms go their separate ways", O'Reilly Developer Weblogs.
Available at: http://www.oreillynet.com/pub/wlg/3001
Dubinko, M. (14 Apr 2003), "RE: History 101".
Available at: http://lists.w3.org/Archives/Public/wwwforms/2003Apr/0063.html
Udell, J. ( 26 Feb 2003), "iDiscuss: Jon Udell's
Weblog". Available at: http://weblog.infoworld.com/udell/2003/02/26.html
Vint, D. (1 Mar 2003), "XML Schema - Data Types
Quick Reference Card". Available at: http://www.xml.dvint.com/docs/SchemaDataTypesQ
R-2.pdf
Watts, A. (10 Mar 2003), "W3C XForms and Apache
XMLForm". Available at: http://lists.w3.org/Archives/Public/wwwforms/2003Mar/0025.html
"W3C publishes XForms 1.0" (18 Nov 2002),
Propylon in the Pres s . Available at: http://www.propylon.com/news/inthepress/20021118
_W3C_publishes_XForms_1.0.html
APPENDICES
Appendix A xforms1-xml.doc: Example XForms contained within an XHTML file
Appendix B resource-xsd.doc: XML Schema describing the overall structure of the data file
Appendix C
dc-xsd.doc: XML Schema describing Dublin Core elements used in the example
6