Introduction to XForms: XML Powered Web Forms
This chapter is from the book
This chapter is from the book
This chapter is from the book
Since their inception in 1993, HTML forms have come to form the underpinnings of user interaction on the World Wide Web (WWW). The convenience afforded by the ability to deploy applications at all levels of complexity on the Web, and thereby provide consistent end-user access to information and application services via a universal Web client, created a platform-independent environment for electronic commerce across the Internet.
However, building on the essential simplicity of HTML forms has resulted in an extremely complex Web programming model; today, Web application developers are forced to work at different levels of abstraction—and, consequently, duplicate application and business logic in multiple programming languages—in order to deliver a satisfactory end-user experience. These problems become even more complex given the need to perform electronic transactions with a variety of different devices and user interface modalities. As we deploy Web access to software at all levels of complexity ranging from business back-ends to simple electronic transactions, these issues can be better addressed by revisiting the design of HTML forms that are the essential underpinnings of the transactional Web.
XForms—a revision to the existing HTML forms technology developed by the World Wide Web Consortium (W3C)1—builds on the advantages of XML to create a versatile forms module that can stand the Web in good stead for the next decade.
Section 1.1 traces the evolution of Web applications and describes the problems inherent in the present-day Web programming model that motivated the work on XForms. We design a simple questionnaire application using HTML forms in Section 1.2 and enumerate the software components needed to deploy the questionnaire on the Web. We then recast this application in XForms in Section 1.3 to give a bird’s-eye view of the various components that constitute W3C XForms. We conclude this chapter with a summary of key XForms features and their benefits in Section 1.4. The remaining chapters of this book will cover these components in detail along with numerous examples that illustrate their use.
1.1 Background
HTML forms for creating interactive Web pages were introduced in 1993. The addition of a handful of simple markup constructs that allowed HTML authors to create input fields and other user interaction elements enabled Web sites to deploy Web pages that could collect user input as simple name-value pairs. The values input by the user were transmitted via HTTP and processed on the server via Common Gateway Interface (CGI) scripts. This new innovation spawned a multitude of interactive Web sites that experimented with these constructs to create interfaces ranging from simple user surveys to prototype shopping applications.
As electronic commerce on the Web gained momentum during the mid-90s, Web developers moved from experimenting with HTML forms to deploying real end-user applications to the Web. These forms-powered HTML pages provided a Web interface to standard transaction oriented applications. In this programming model, the Web developer authored a user interface in HTML and created corresponding server-side logic as CGI scripts that processed the submitted data before communicating it to the actual application. The combination of the HTML user interface and the server-side logic used to process the submitted data is called the Web application. The Web application in turn communicates user input to the application, receives results, and embeds these results in an HTML page to create a user interface to be delivered as a server response to the user’s Web browser.
This method of deploying electronic transactions on the Web where end users could interact via a standard browser created a platform-independent environment for conducting electronic commerce across the Internet. Examples of such Web applications range from CNN’s opinion polls to electronic storefronts like amazon.com. During this period, the server-side components making up Web applications gained in sophistication. The simple-minded CGI script came to be superseded by server-side technologies such as Java servlets, specialized Perl environments optimized to run in a server context such as Apache’s modperl,2 and a plethora of other server-side processing tools. These technologies were designed to aid in the processing of user data submitted via HTTP and the generation of dynamic content to be transmitted as the server response. The underlying HTML forms technology however remained unchanged—except for the addition of file upload and client-side Javascript to enable a more interactive end-user experience on the client.
As the ecommerce Web matured, vendors rushed to deploy server-side middleware and developer tools to aid in the authoring and deployment of interactive Web applications. By this time, such tools were almost mandatory, since the essential simplicity of HTML forms resulted in scalability problems when developing complex Web applications.
Consider some of the steps that are carried out by a typical Web application. User data obtained via HTTP is validated at the server within servlets or other server-side software. Performing such validation at the server after the user has completed the form results in an unsatisfactory end-user experience when working with complex forms; the user finds out about invalid input long after the value is provided. This in turn is overcome by inserting validation scripts into the HTML page. Notice that such scripts essentially duplicate the validation logic implemented on the server side. This duplication often has to be repeated for each supported browser to handle differences in the Javascript environment.
Using this programming model, developing, deploying, and maintaining a simple shopping application on the Web require authoring content in a variety of languages at several different levels of abstraction. Once developed, such Web applications remain expensive to maintain and update. Notice that the move from experimenting with Web interaction technologies to deploying real-world applications to the Web brings with it a significant change; in most real-world scenarios, the application to be deployed to the Web already exists. Even in the case of new applications, only a portion of the application in question gets deployed to the Web. As an example, only the electronic storefront of a shopping site gets deployed to the Web; such shopping sites are backed by software that manages customer information, product catalogs, and other business objects making up an electronic store. Thus, deploying complex interactive sites involves creating the business logic and then exposing relevant portions of this application to a Web application that creates a user interface accessible via a Web browser.
One way of simplifying this development process is to make business applications themselves aware of the need to deliver a Web user interface. This approach is followed by many of today’s popular middleware solutions, with some commercial database engines going so far as to incorporate a Web server into the database. However, making back-end business applications aware of the details of the user interface markup can make systems difficult to evolve and maintain. The resulting lack of separation of concerns ties Web applications to a particular back-end system.
As we deploy Web access to software at all levels of complexity ranging from business applications to electronic transactions, the problems outlined earlier can be better addressed by revisiting the essential underpinnings of the transactional Web. Today, Web applications need to be accessible from a variety of access devices and interaction modalities—Web applications may be accessed from a variety of clients ranging from desktop browsers to smart phones capable of delivering multimodal3 interaction. Thus, a travel application that is being deployed to the Web needs to be usable from within a desktop browser, a Personal Digital Assistant (PDA), and a cell phone equipped with a small display. Thus, the interface needs to be usable when interacting via a graphical or speech interface.
Notice that the problems with HTML forms outlined earlier become even more serious when confronted with the need to perform electronic transactions with a variety of different end-user devices and user interaction modalities.4 W3C XForms5—a revision to the existing HTML forms technology from 1993—builds on the advantages of XML to create a powerful forms module that can stand the Web in good stead for the next decade.