This material is posted here with permission of the IEEE. Such permission of the IEEE does not in any way imply IEEE endorsement of any of Helsinki University of Technology's products or services. Internal or personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from the IEEE by writing to [email protected]. By choosing to view this document, you agree to all provisions of the copyright laws protecting it. ©2004 IEEE. Reprinted, with permission, from Proc. of the IEEE Sixth International Symposium on Multimedia Software Engineering (MSE2004), Miami, FL, USA, December, 2004, pages 232-239. A Configurable XForms Implementation Mikko Honkala Petri Vuorimaa Helsinki University of Technology, TML Helsinki University of Technology, TML P.O. Box 5400, FIN-02015 HUT, FINLAND P.O. Box 5400, FIN-02015 HUT, FINLAND Mikko.Honkala@hut.fi Petri.Vuorimaa@hut.fi Abstract scripting and markup can be cumbersome, since it creates semantic and performance discontinuities [4]. XForms is a new language for defining dynamic forms Interaction in an application often depends on the device and user interfaces for the World Wide Web. In order to and environment at hand. For instance, the interaction with take advantage of the user interaction related features in a mouse and a desktop computer differs from the interac- the language, a client side processor is needed. This paper tion with a smartphone, let alone speech interaction with a describes a configurable open source software implementa- normal phone. The traditional interaction technologies usu- tion of XForms. The main goal of the implementation is to ally target just one environment or device. Applications run- conform to the World Wide Web Consortium’s XForms Rec- ning in the WWW can be accessed with different kinds of ommendation. The other goals are external to the XForms devices, but still the interaction is usually designed to just specification and are related to the portability and config- one or few different usage environments. Due to limitations urability of the processor. The important questions are re- in HTML forms, it is not easy to target the same applica- lated to implementing an XForms processor for diverse en- tion to different devices. vironments, and the integration of XForms and other XML Due to these problems, W3C has developed a successor languages with different layout models. In the paper, more to HTML forms, XForms [5]. It removes need for scripts, detailed requirements are gathered from these goals. Also, and separates content from the presentation. Furthermore, the design and implementation are presented in detail, in it uses an abstraction of an user interface, enabling inter- order to give insight to the more difficult and non-obvious action across different modalities and devices. Other im- parts of the software. The results of the paper cover the run- portant questions are related to implementing an XForms time requirements of the XForms processor. processor for diverse environments, and the integration of XForms and other XML languages with different layout models. Currently, the most interoperable option for developing a cross-platform client, (i.e., a browser), is Java. Programs 1. Introduction written in Java can be run in desktops, smartphones and digital-TV set-top boxes. All of them have different libraries Although HyperText Markup Language (HTML), the available, though. main content language of the World Wide Web, was orig- There are XML-based form technologies that predate inally just a document description language, lately WWW XForms, including XFDL 1 and XFA 2. Also, there is cur- has been transformed into a platform for interactive services rently a lot of effort put into XML-based GUI technologies. [1]. HTML, being a device and operating-system indepen- Some of them are mainly designed for defining GUIs for dent, is still used to describe the user interface of the ser- stand alone applications, including Glade 3, Netscape XUL vices. However, the GUI technology behind the services, 4 and Microsoft XAML 5 , while some address the office HTML forms, is now outdated. The complexity of today’s applications is far greater than what was imagined when the 1 Extensible Forms Description Language (XFDL) 4.0, John Boyer, technology was first invented. Therefore, today’s high-end Tim Bray, Maureen Gordon, 2 September 1998. Available at: forms have to use complex client-side ECMAScript [2] pro- http://www.w3.org/TR/NOTE-XFDL 2 XFA-Template Version 1.0, Gavin McKenzie, 14 June 1999. Avail- gramming to achieve form field validation and simple com- able at: http://www.w3.org/1999/05/XFA/xfa-formcalc.html putations (or bounce the form back and forth to the server). 3 Glade. Available at: http://glade.gnome.org/ Heavy use of scripting inevitably leads to low maintain- 4 XML User Interface Language (XUL) 1.0, David Hyatt (ed.), Avail- ability and accessibility [3]. Also, for the author, using both able at: http://www.mozilla.org/projects/xul/xul.html application space, namely InfoPath 6 . The configurable im- plementation reported in this paper is based on an earlier prototype the authors have made [6]. Dynamic calculations, and their implementation within XForms have been stud- ied in [3]. Dynamic user interfaces, such as repeating con- structs have been studied in [7]. The relationship between the latest XHTML 2.0 and XForms has been described in [8]. 2. The XForms language XForms 1.0 Recommendation [5] is the next-generation Figure 2. The external requirements. Web forms language. It solves some of the problems found in the HTML forms by separating the purpose from the pre- sentation and using declarative markup to describe the most it’s use is optional to the author. The Model Item Proper- common operations in form-based applications. ties (MIP) are dynamic constraints written in XPath. They can reference other values in the instance data and are dy- namically evaluated by the XForms Processor. With MIPs, it is possible to define dynamic calculations and cross-value checks, which are not possible with XML Schema. Fig. 1 also depicts the typical usage scenario of XForms. It consists of a client, which includes an XForms processor and an HTTP server with application specific software. The user interface of the application is defined with static doc- uments, written in XForms combined with a host language, such as XHTML. Similarly, the structure of the data is de- scribed with static XML Schema documents. The applica- tion logic is responsible for sending and receiving XML in- stance data, which correspond to the data gathered from the user. Compared to current Web applications with HTML, a lot Figure 1. The XForms layers. of the user interface processing is transferred to the client in XForms. This frees bandwith and improves the user expe- rience. Additionally, the application data is separated from XForms separates the form into three main lay- the user interface, which helps to build modular software, ers: Model, Instance, and User Interface (cf. Fig. 1). which is easier to maintain. Instance An arbitrary XML document that is modified by Because of the quite heavy dependencies on XML pro- clientside user interaction, then submitted to a server. cessing tools, such as XML Schema and XPath, XForms may be difficult to implement in a restricted device, such as Model Uses XML to define the constraints on items of the a smartphone. To overcome this problem, W3C has speci- instance, which includes data types and ranges as well fied a smaller profile of the language, called XForms Basic as computational relationships. [9], which does not include full Schema capabilities. User Interface Defines how the form is shown and ex- presses bindings to instance items. User input is gov- 3. Requirements for the XForms processor erned by rules in the model for the instance item being modified (through a bound input control). The requirements for the XForms processor come from The Model layer includes the XML Schema and the multiple directions. The main goals can be divided into five Model Item Properties. The structure and the data types categories, as depicted in Fig. 2. The main goal was to have of the instance data can be defined using the schema, but a conforming XForms processor. The other goals were ex- ternal to the XForms specification and were related to the 5 XAML, Available at: http://msdn.microsoft.com/. portability and configurability of the processor. They are 6 Microsoft InfoPath, Available at: Java VM support, XML Processing Libraries, UI Toolk- http://www.microsoft.com/office/infopath/prodinfo/default.mspx its, and Host Languages. The requirements that we derived from these goals are described in detail in the following list. These requirements are the focus of the implementation part of this paper. XForms Processor: Requirements. XForms Full XForms 1.0 Support. XForms Basic Can be configured to run in XForms Basic mode with reduced processing. Java VM Support: Requirements. Desktop Java 2 Standard Edition (J2SE) support. Personal Java Runs in Personal Java 1.1 and Java 2 Micro Edition (J2ME) Personal Profile. Figure 3. The architecture of the processor. MHP Multimedia Home Platform (MHP) support. XML Processing: Requirements. <bind nodeset="items/item/total" XML Should allow third party XML parser, XPath, calculate="../units * ../price" and XML Schema libraries. relevant="../units > 0" /> UI Toolkits: Requirements. <bind nodeset="totals/subtotal" Swing Supports Swing Toolkit in Desktop. calculate= "sum(../../items/item/total)"/> AWT Supports Abstract Windowing Toolkit (AWT). <bind nodeset="totals/tax" Havi Uses Havi Toolkit in digital tv set-top boxes. calculate="../subtotal * Host Languages: Requirements. ../../info/tax"/> CSS Languages Supports CSS flow and box model.