Computer Power User Article - Coder's Corner: XML

Computer Hardware Reviews at Computer Power User Magazine. Your source for overclocking software guides, building your own computer, pc cooling and computer modding.

Coder's Corner: XML

Email This

Caught In The Web October 2002 • Vol.2 Issue 10 Page(s) 76-77 in print issue
Add To My Personal Library
Coder's Corner: XML Device-Independent Forms With XForms

In Coder's Corner: XML, Ian Graham shows you how to program with XML. Ian is the author of numerous books pertaining to Web development, including "The HTML Sourcebook" and "The XML Specification Guide."

Last month, we discussed XUL (XML User Interface Language), the Mozilla Project's platform-independent language for defining a user interface's component parts and layout. Mozilla's browser uses XUL to define the user interface, including the nature, position, and functional connections of the various user-interface controls.

XUL is flexible but has some design limitations, including device-dependency. XUL assumes a user-interface model based on a standard desktop computer GUI. XUL elements essentially correspond to real widgets being displayed or rules defining how these widgets are positioned. A XUL document defines the relative positions and layouts of these elements (with help from CSS), thereby defining the overall user interface.

This limitation isn't a problem for Mozilla, where XUL's role is to define traditional interfaces. In other cases, this limitation can be a big problem. Suppose you need a single Web app for a standard computer interface and a PDA. The interface needs to be very different. XUL simply doesn't fill the bill.

XUL still has an important role because regardless of how an app's user interface looks, the interface's purpose is unchanged: gather and display the same information. The ideal is an XML language that can express the interface's purpose in a device-independent way and that can be easily mapped onto an appropriate presentation.

This illustration shows how the X-Smiles browser renders an XForms example document in different devices, including the cell phone, desktop, and PDA interfaces shown here.

Device Independence

This is the goal of the XForms language, an XML standard being developed by the W3C. Work on XForms started as an offshoot of XHTML work, as XHTML forms were weakly designed and needed changes to make them as flexible and functional as desired. A separate forms working group was created in 2000, with a goal of a device-independent language for describing form-style input that:

• Is device independent but works well on standard desktop Web browsers

• Supports universal accessibility (for alternate user-interface modes)

• Strongly separates presentation from purpose (such as model from view)

Doing this meant many substantial changes with respect to HTML forms, which partly explains why more than two years later, the XForms spec still isn't finished. However, the draft standard is stable, and XForms-based products are being released.

In short, XForms has three main parts, including:

• XForms user interface. This set of elements defines standard interface-independent controls, such as selectable lists, buttons, and text input mechanisms. These will eventually replace the current XHTML form controls. XForms also has an <output> element to reference live data in a form. A user interface can use this to include live data in the displayed content.

• Instance data. This is an internal XML representation of the data associated with a set of form controls. Having a separate instance data component cleanly separates the data from the controls. XForms user-interface controls are bound to instance data content using explicit XPath expressions (XML's mechanism for referencing locations in an XML document).

• The XForms model. This is the overall XForms processing model. For example, when a user submits a form, the XForms model defines how data is bundled for delivery (it's typically turned into a stream of XML data corresponding to the data content of the instance data). The XForms model also defines ways of setting—using XML markup—constraints on form data. For example, a constraint might be text entered into a box that must be a number greater than five or that a string must match the pattern for an email address.

All this may seem confusing, but consider this XHTML + XForms example:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xf="http://www.w3.org/2002/01/xforms" >
<head>
<title>Example of XForms in XHTML</title>
<xf:model>
<xf:instance />
<xf:submitInfo method="post"
action="http://www.example.com/submit.pl" id="myForm" />
</xf:model>
</head>
<body>
<h1> Example of the Form</h1>
<p>Here is a simple example XForm form, intermingled with XHTML. </p>
<group xmlns="http://www.w3.org/2002/01/xforms" ref="purchaseInfo">
<selectOne ref="@ptype">
<caption>Pet Type you Want to Buy</caption>
<choices>
<item>
<caption>Dogs</caption> <value>lupus</value>
</item>
<item>
<caption>Cats</caption> <value>feline</value>
</item>
....
</choices>
</selectOne>
<input ref="CardNo">
<caption>Credit Card</caption>
</input>
<input ref="Exp">
<caption>Expiry Date</caption>
</input>
<submit submitInfo="myForm">
<caption>Buy that Pet!</caption>
</submit>
</group>
</body>
</html>

Here the HTML element declares that the prefix xf corresponds to the XForms namespace. Inside the HTML head element there is XForms markup declaring the model (xf:model) for the form. The xf:instance element creates an instance data element (in this case, there is no data, as the xf:instance element is empty), while the xf:submitInfo element labels this form submission mechanism (id="myForm") for reference by specific form UI components. It also defines what to do when the form is submitted (post it to the indicated URL).

The XForms user interface markup is inside a group element inside the body of the HTML document. On group the xmlns attribute is used to reset the default namespace to that of the XForms language. Thus, you don't need a prefix for XForms elements inside group. Group also has a ref="purchaseInfo". This attribute defines where in the instance data tree the data from this form UI element should go. Values of ref attributes are actually Xpath expression defining locations within the instance data tree. ref="purchaseInfo" means the data should go inside a purchaseInfo element at the root of the instance data tree.

First inside the group element is a select-One element containing a caption and set of choices (each choice in an item element). The ref="@ptype" means that in the instance data tree, the data from the selectOne will be stored as the value of an attribute named ptype on the purchaseInfo node. These XPath expressions can seem complicated, but the idea is pretty simple. The ref expressions define where in the output data structure the form data should go.

Last, two input elements define captioned text input components, while the submit element (also with a caption) defines the button that will submit the form. The submitInfo="myForm" attribute attaches this submit function to the submitInfo element with this same label.

How this document displays depends on the device and how the device's UI system best maps the UI components onto the display. This can vary greatly, but note how the XForms markup uses concepts that are independent of specific presentation details. Of course, CSS and other mechanisms can help customize and/or refine the styling, and CSS supports a media types option so different CSS style sheets can be applied to most types of devices.

So, Where's The Beef?

This sounds neat, but where are the real-world XForms apps? There aren't many. XForms is pretty new. However, XForms will be a core component of XHTML 2.0, so you can imagine there will be plenty of XForms somewhere in your future.

by Ian Graham

(NOTE: Full examples of the documents in this article are available at www.utoronto.ca/ian/articles/oct02.)

Want more information about a topic you found of interest while reading this article? Type a word or phrase that identifies the topic and click "Search" to find relevant articles from within our editorial database.

Home Copyright & Legal Information Privacy Policy Site Map Contact Us