Organizations have evolved a variety of systems to deal with the increasing levels of information they must regularly process to remain competitive. Business Process Management (BPM) systems presently take a wide variety of shapes, often including large amounts of ad hoc scripting and one-off implementations of business rules. Such systems tend to be developed incrementally, and pose a significant obstacle to continued development and maintenance.

A World Wide Web Consortium (W3C) specification called XForms aims to change this situation. This article compares XForms to ad hoc solutions to produce a real-life application: the creation of XML purchase orders.

Note: The material in this article is adapted with permission from a chapter of the book XForms Essentials, to be published by O'Reilly & Associates in August 2003.

The Problem
Of the several efforts that are under way to define XML vocabularies for business, the most promising seems to be UBL, the Universal Business Language. At the expense of being slightly verbose, the vocabularies defined by UBL do a remarkable job of capturing all of the minor variations that occur in real-world business documents across diverse organizations. For the sample application in my book, I chose a purchase order, since that kind of document is well-understood and demonstrates several features, such as repeating line items, that are customarily difficult to implement. This latest version of this solution is available online at http://dubinko.info/writing/xforms/ubl.

A template UBL purchase order document is shown in Listing 1 (listings can be found at www.sys-con.com/xml/sourcec.cfm).

The Solution
Any number of technologies could be called upon to implement an application that produces purchase orders based on templates like the one in Listing 1. Prior to XForms, a typical solution would employ HTML forms and JavaScript. Microsoft InfoPath, currently in beta as part of Office System 2003, offers a better user experience than HTML forms, but still relies heavily on scripting through an event-driven model. As the remainder of this article will show, a declarative approach as used in XForms can eliminate a substantial amount of complexity from the overall solution.

Since XForms is designed to be used in concert with a "host language," I chose a combination of XHTML 1.1 and XForms for the solution, even though a DTD for the combined language isn't available. Comments in the online version include additional information on some of the XML specifics that result from the integration. Listing 2 shows the starting section of XForms code in the document head.

The xforms:model element is the container for the entire XForms Model, the name given to the definition of what the form does without any regard for how it looks. It is possible to associate an XML Schema with a form, though that option is commented out in this solution, since XML Schema processing would add significant overhead, and the few places that require additional data type information can be easily specified separately. The xforms:instance element, with an src attribute, points to the initial instance data template that was listed earlier. The xforms:submission element indicates that activating submit on this form will write XML to the local file system.

Listing 3 continues with xforms:bind elements, each of which selects a specific portion of the instance data, applying XForms properties to the selection. Such properties define overall constraints that are in force at all times. In contrast, script-based approaches require separate but tightly coupled code to handle initialization and each entry point where important values can change.

The language used to select pieces of XML called nodes is XPath 1.0, also known as the selection language underlying XSLT, XPointer, and XML Signature. XPath expressions walk a path from a given starting point through an XML document using a syntax similar to file system navigation. XForms includes defaulting rules that simplify most of the XPath selection expressions that point into the XForms model, called model binding expressions. The first model binding expression in Listing 3 selects the one-and-only u:IssueDate instance data node, marking it as required and giving it the XML Schema data type xs:date, which provides the hint that this particular data should be entered with a date-optimized form control. The second model binding expression in Listing 3 applies to however many u:Quantity elements happen to exist at any given time, a quantity which will vary as line items are added or removed, marks all of them as requiring user entry, and gives the XML Schema data type xs:nonNegativeInteger. In contrast, a purely script-driven approach would need to actively watch for the addition or removal of line items in order to apply the properties to altered nodes.

The next few model binding expressions, in Listing 4, set up the two calculations that are fundamental to a purchase order: the total amount for a line item (price times quantity), and the total for the whole order (sum of all line items).

The calculate attribute holds an XPath expression that gets evaluated whenever needed to determine a new value for the node to which it is attached. Just as file system paths can be based on a current directory, XPaths can be relative to a context node, and can even backtrack toward the root node with the familiar double dot (..) abbreviation. XPath expressions can also contain a handful of arithmetic operators and common functions. The calculation for line items is ../u:Quantity * ../u: Item/u:BasePrice/u:PriceAmount, where the asterisk means multiply, and the operands on either side of it are path expressions, relative to whichever u:LineExtensionAmount element is being recalculated. In turn, the calculation for the grand total is sum(../u: OrderLine/u:LineExtensionAmount), which uses the function sum() to add up all the values from individual u:LineExtensionAmount nodes. Like a spreadsheet, recalculations will occur as needed with no special programming effort, and dependencies among calculations will automatically be handled in the correct order so, for instance, individual line items will always be multiplied out before the overall total is summed up.

The online version includes a few more tricks that space does not allow discussion of here. In XForms, it is possible to define secondary XML instances that can be used for temporary storage in a form. The online solution uses this technique to centrally keep track of possible currency values used in the purchase order.

Listing 5 shows content that begins the body section of the XHTML host document. It gives you a good feel for the kind of code that makes up an XForms user interface. Form controls have names like input, select1, or output, which suggest the intent of the control without committing to a specific incarnation like "radio buttons" or "pop-up list". This level of abstractness ensures that XForms solutions will be workable across different kinds of devices, including phones, PDAs, and eyes-free browsers. On the other hand, it leaves room for designers to add customization through Cascading Style Sheets (CSS). As of this writing, a W3C Working Draft for "CSS3 Basic User Interface," which includes properties that will enable designers to achieve the fine level of control they desire, is available at www.w3.org/TR/css3-ui. The XForms engine that renders the form, however, will make reasonable choices for how to render form controls, including helpful optimizations. For example, browser-class XForms engines will recognize that the first xforms:input element is attached to a node with a data type of xs:date, and will automatically use a calendar date-picker control.

Other features of XForms user interface markup stand out in Listing 5. The controls all use the ref attribute to point to which instance data node should store the user-entered value. (Another option, not used here, is to avoid specific paths in the user interface by using ID and IDREFs.) Each form control element, except for xforms:output, has a required xforms:label child element, which ensures that form controls will have an accessible label directly associated.

The second form control demonstrates more unique features. A hint attribute appearance="minimal" suggests that this part of the interface should be given minimal screen real estate when not activated - for example a pop-up list. Another attribute selection="open" indicates that the user should be able to enter arbitrary values not on the list. Further, a kind of repetition is going on here; the single xforms:itemset element maps to a number of list choices defined elsewhere.

A similar repetition occurs in Listing 6, which shows the xforms:repeat element. The element xforms:repeat causes a repetition of user-perceived content, once for each node in a given set of nodes - exactly the behavior needed to populate the line items in a purchase order. All the content of xforms:repeat is effectively duplicated as many times as there are line items, which can be dynamically added and removed. The first form control on each line item is xforms:range, which allows a smoother way to select a value than typing a number, for example a sliding indicator. The range here is from 1 to 9, with the attribute incremental="true", which causes changes to this control to interactively propagate throughout the document. The rest of the repeating form controls are similar to ones already used in this solution.

Challenges
The two main challenges facing developers deploying XForms solutions today are deciding on a host language and configuring stylesheets for all target browsers. Eventually XHTML 2.0, including XForms as the forms module, will be finalized, providing a known and stable target for browsers to implement and designers to write toward. Until that time, however, a reasonable approach is to use XForms elements within XHTML 1.0 or 1.1, without the luxury of DTD validation.

Getting the stylesheets right is trickier, but getting easier day by day as XForms engines get smarter about CSS support, and as the CSS specifications themselves get more polished. The test suite for XForms 1.0, at www.w3.org/MarkUp/Forms/Test, contains some fine examples of CSS that work well across all common XForms browsers. One specific hint, already used in this article, is to include an xforms:group element wrapper to cause the contents of the group to be formatted as a block section, which works particularly well inside an xforms:repeat element.

Conclusion
XForms has made vast strides in 2003, becoming a technology suitable for production use by early adopters. Already, businesses are using XForms to produce real documents similar to the one shown in this article. The combination of an open standard with a wide variety of both free and commercial browsers makes a powerful business case for deploying XForms solutions.

Unlike many other XML standards, XForms has remained small, simple, and true to its roots - addressing only well-known and well-understood problems, and providing a universal means to express solutions to these problems. Part of the appeal of XForms is the reuse of proven technologies, such as XPath, for which developers are more willing to invest the time necessary for learning. XForms can also leverage existing XML infrastructure, including XML Schema and Web services components. By embracing a declarative approach, XForms can simplify the code involved in BPM systems, as well as make future maintenance tasks easier.