Using W3C XForms in Office Applications

HTML Forms

HTML, the W3C's Hypertext Markup Language HTML, is the now ubiquitous language of the World Wide Web. Forms were introduced in HTML, version 2.0. HTML2 In HTML, logical forms may be embedded in a document, which in turn may contain form controls. The data model supported by HTML forms is quite simple: A set of name/value pairs. Each form control operates on a single value, and is identified by a unique name. Upon submission, each control contributes its name and value to the submission data, which is then sent to a given server, typically as a HTTP GET or POST request.

The set form controls supported by HTML is small, but easily sufficient for many applications: The main controls are text boxes, check-buttons and radio buttons, and buttons used for submission.

HTML does not have support to check values against any given rules. There is no interaction between controls, except for radio buttons which may be grouped together so that only one button can be pressed at any time. (Such a group of radio buttons may by and large be considered a single control, however, which cannot have any additional interactions with other controls.) Additional features, such as input validation, may be added through use of ECMA script (formerly: JavaScript) ECMAScript, which are executed on the client.

The HTML 2.0 form model has remained largely unchanged until today. The W3C HTML Working Group effort to create a more ambitious and more useful forms functionality for inclusion into XHTML has eventually led to the specification of XForms, which is described below.

Example HTML Form

Database Forms

Electronic forms are established as the premier input tool for database applications. Data entry in such applications, e.g. one of the many front-end applications for SQL databases, typically consists of forms, populated with controls. In addition to standard controls similar to those that HTML supports, databases often support data-type specific controls, such as number, date or image controls. Additionally, databases often support navigation controls (VCR-style forward/backward buttons), to allow for easy navigation through a given data set.

The data model supported by such database controls is usually that of the underlying database. For SQL databases, the data model usually is an SQL result set. Each control is bound to one column of the result set, form where it obtains its initial data, and to where it writes updated data. Data validation may be supported against the supported SQL data types (e.g., text, number, etc.) and their given constraints (e.g. length, precision, etc.). Interaction between different controls is generally not supported. In database context, form data is generally linked directly to the database and will be written back automatically, and no separate submission process is necessary.

Database Form

Office Applications

Since office applications have become the Swiss Army Knife of the modern office worker, they naturally support forms in a number of contexts. What may come as a surprise to someone familiar with today's data processing chains is that the perhaps most common use of forms in office is the creation of form look-alike documents without any inherent form capability at all. These documents create a form layout, with the blanks that constitute the fill-in-the-blanks nature of a form being, well, blanks. That is, they may also be a sequence of underscore characters, or tabs (or other non-printable characters) that are underlined or otherwise marked. The only functionality these forms provide is that they can be printed out, and can then be used like any other paper form. Electronic processing of form results is not possible.

To facilitate processing of form results, office applications have subsumed both of the previously mentioned form uses: HTML-type and database-type forms. The exact level of support varies between the different products, but to the best of the author's knowledge equivalent functionality is supported in all full-featured office suites. Using the example of the Open Source OpenOffice.org application, text or spreadsheet documents may contain form controls grouped in logical forms. Depending on the setting of such a logical form, the form controls may either be used for HTML-style (and HTML compatible) data submission, or may be bound to a result set of an SQL query.

The simple data models of HTML or SQL forms limit the amount of logic or functionality that can be incorporated into such a form. More complex form behavior can only be accomplished using scripting. However, the simple data model of HTML or SQL forms does have a major advantage: Such forms are very easy to author, since the forms designer does not need to be concerned with details of a potentially complex data model. This allows form authoring by comparatively unsophisticated users.

W3C XForms

W3C XForms, which will be introduced in more detail below, allows the creation of much more sophisticated forms. The XForms standard was developed in the context of enhanced support for XHTML, but is suitable for much broader range of applications. Integrating XForms into office applications will significantly enhance the forms capability of office suites. Due to the very rather different background of end user centric office applications on one hand, and the W3C technical activities on the other, integration of XForms into office suites poses a number of challenges. These challenges, plus details for the solutions used by the Open Source OpenOffice.org software , will be detailed in the following sections.

Embedded Vocabulary, and Decoupled Presentation

A major element of any paper form is its presentation. In fact, due to lack of any automatic processing, paper forms rely entirely on their presentation to guide the user. Thus, any form will have carefully chosen positioning of its fields, and explanatory text that indicates the user which values are expected for any given field. Consequently, presentation plays an important role for electronic forms as well.

The probably most profound feature of XForms is that it does not deal with presentation at all. Instead of attempting to recreate yet another XML language to describe textual and graphical elements and their placement, XForms is designed to be embedded in a host vocabulary. It is the responsibility of the host language to define the presentation of the form, while XForms itself defines the form content. This embedding is important for accessibility and software reuse. With respect to office integration, it allows us to easily include XForms into XML office document formats.

Given the origin of XForms as a W3C technology, XHTML (with CSS) and SVG are the commonly used host languages for XForms. For office applications, the OASIS OpenDocument XML File Format (OpenDocumentTC, OpenDocument) is the natural choice.

XForms Model - Data and Logic

The XForms model contains both, the data and the logic of a form. The model has three constituent elements:

• Instances, which contain the data in the form of XML sub-trees.
• Submissions and bindings, which contain the logic of a form.

XForms UI

XForms provides for a number of UI elements for rich form presentation. Most prominently this includes a comprehensive list of form controls. These are not discussed here, since the XForms integration discussed in this paper reuses controls that are already found in the OpenDocument format.

Scope of Integration

A critical question for the integration of new technology is how much to support at all. In the interest of providing users with an easy transition from their familiar environment into the new, XML-centric XForms functionality, we decided to reuse existing functionality where possible. So instead of adopting the XForms UI layer, i.e. the set of XForms controls, the already existing OpenDocument controls (OpenDocument, Chapter 11, Form Content) were reused. These controls may now be bound to an XForms model, using the xforms:bind attribute in the file format, and a UI (described below) in the program.

As a corollary, OpenOffice.org is only a partial implementation of the XForms specification, and hence cannot be fully compliant to the standard. In keeping in line with the policies of the OpenDocument format a proper subset was used. Parts of XForms that are used are used as-is, and are in not re-defined or altered in any way. In addition to allowing a clean definition of the XForms embedding, this allows future steps towards fully supporting the standard in its entirety.

Using an XForms -Enhanced Office Document

The use of forms in an XForms-enhanced office is arguably the easiest part of the XForms/Office integration: Since simply using a form does not require any exposure to the technology, the integration of the forms use mode was trivial. Since XForms are embedded in the standard office format, files open the same as any other document. Since the same controls are used, it also looks the same as any other office form document. The document will even mostly behave the same as previous generation forms, except of course where XForms features, such as data validation or automatic calculations, are involved. Care was taken to provide the user with human-readable error messages, but otherwise no further measure were considered necessary.

Example: XForms in OpenOffice.org

Creation and Editing of W3C XForms Document

The primary function of any office productivity tool is the creation of documents. With respect to XForms, this is a much steeper challenge than merely using XForms, in that it requires the user to comprehend several concepts that are rather unfamiliar to the average office user. This includes:

• Using XML as data model.
• Indirectly binding controls to data elements.
• Adding logic by assigning properties to data items.
• XPath, an expression language which computes values on tree structures.

To someone used to working with W3C technologies, such as the audience of this paper, all of these items are likely familiar, or at least easily comprehensible. However, each of these requires a significant learning effort and presents a significant step to the intended audience of an office suite.

To ease the learning curve for these users, a guiding principle in the UI design for XForms was to allow the user to achieve simple yet useful results without requiring a full grasp of the underlying technologies. This will hopefully allow users to start with a complexity no greater than the typical office environment, and then gradually increase the use of W3C related technologies.

XML as data model

XForms uses XML instances as its data repository. Fortunately, the XForms standards already provides a very useful shortcut for creating XML instances, the so-called 'lazy author' processing. (XForms, Chapter 4.2.2) This is essentially a rule which states that when an instance is references, but does not yet exist, and the binding expression is a valid XML QName, then an element with that name is automatically added to the instance.

Making use of this, a user need only enter a (mostly) arbitrary string as binding expression, without even having to realize that XML is involved at this point. ('Mostly' arbitrary, since the XML syntax rules apply, so for example no whitespace or punctuation is allowed.)

Property Browser

How can we provide a user with an upgrade path from this very basic use of XForms? The actual XML instance data, which is generated by the 'lazy authoring' rules when the form is used, is visualized using a tree control in the so-called Data Navigator. This way, a user can 'grow' from the implicit use of XML via 'lazy authoring' to the more conscious use of XML's modeling ability.

Example

So, what is the simplest possible way to create an XForms document in OpenOffice.org?

• First, you go to the well known File -> New menu, and choose XML Form Document. This will create an empty document, which contains an (empty) XForms model.
• Then, you can insert a control into the document, e.g. by using a button on the forms control toolbar.
• Next, edit the control's properties. In the property browser, choose the pre-defined XForms model, and enter an arbitrary XML name (like “hello”) into the field 'binding expression'. This will automatically create a binding with a suitable binding expression, and bind the control to it.

When this form is deployed, the 'lazy authoring' rule kicks in, and an instance with a suitable XML element is created.

Example 'lazy author'

Bindings and Model Item Properties

Bindings are explicitly displayed (and may be edited through) the DataNavigator. They serve the dual functionality of binding a control to its node in the DOM tree, as well as to assign Model Item Properties to nodes in the DOM tree. For many simple tasks, we have made these functions available more directly, so a user needs not be aware of this indirection:

• As for non-XForms forms, Control properties may be edited through the control's property browser. The property browser also contains a tab page for the data source, which in the XForms case offers direct access to the binding the control is bound to. It will create a binding on the fly if none has been assigned yet.
• The DataNavigator displays the XML tree in the instance view. Nodes from this tree may be dragged into the document. This will create a suitable control, depending on the assigned data type, and a suitable binding.
• There are several ways to access or assign model item properties: Properties can be set either directly on XML nodes (through the DataNavigator), through a control's control property page, or through the binding itself. In the first two cases, the user need not be aware of the binding mechanism, as suitable bindings are determined (or created) automatically.

Editing Model Item Properties

XPath Expression Preview

Possibly the greatest learning curve is with the XPath expression language. To make this easier, there are several ways to avoid the use of XPath altogether: Whenever bindings are created automatically, a suitable XPath expression is derived by the program. Also, many Model Item Properties essentially specify boolean values. For these, a simple check-box can be used to statically enable or disable the property.

For dynamically computed model item properties, XPath must be utilized. To make this easier for the inexperienced user, an optional preview is included, which will show the evaluation result of the current expression as the user types along. This direct feedback will allow a user to judge directly whether the expression works as intended.

XPath Expression Preview

Invoice

This example shows an invoice. This invoice makes use of several XForms features:

• data can be validated
• results may be computed automatically (per line, tax amount, rebate, etc.)
• some business logic is applied (e.g., rebate applies only for sums larger than €500)
• currencies are converted, using currency data stored in a second XForms instance
• the result data may be submitted as UBL data UBL

The resulting XForms model that describes this invoice may be re-used in XForms compliant products. The form and the control could be converted, e.g. To XHTML + XForms, using XSLT.

Example invoice

Conference Paper

This example shows this conference paper being prepared using StarOffice. It combines the traditional strengths of office applications with XForms: The structured author meta-data has been stored in an XForms instance, and may be edited using XForms controls. The document body is a conventional word processing document. Conversion into IDEAlliance's XML format was accomplished using XSLT, which can obtain the structured meta-data directly from the XML instance, and converts the body text from the OpenDocument format into the desired target format.

Example Conference Paper