Introduction and Motivation

Among the many constituents of the World Wide Web, as it exists today, a very important part is the graphical user interface, mostly in the form of HTML forms. HTML forms provide a means for handling client inputs and also for handling bidirectional flow of data between the client and the server.

HTML forms typically include a number of elements specifically for handling data. These elements may be either named or unnamed. A named element requires a name attribute for form processing and includes fields like input, textarea, select etc. whereas an unnamed element is often included with a form to fulfil a special purpose. For example, reset is used to set all named form fields to their default values.

The named elements may again be of different types; defined by the kind of values that they are designed to handle. A input field of type text is designed to take a single word or line of text whereas a input field of type radio is designed to reflect a single choice among a number of choices, a input field of type checkbox is designed for a situation when more than one answer is acceptable.

Further, most field values are visible to the user. But, a input field of type hidden is never visible to the user or a field of type password where the user input is visible in a form that reveals nothing about the field value. The number of fields, type of a field, the nature of values a field can be assigned, are all design-time decisions taken when the form is first conceptualised.

Also, known at design-time, though seldom modelled, are the underlying relationships amongst form fields. These relationships are implied at all times; from the moment the HTML page (containing the form) is loaded by the browser to the moment the form is submitted to the server. Traditionally, these relationships are handled at the server-side which we will argue is neither good for the server traffic nor for the network bandwidth. We take a simple example to make our point. Consider an online purchase order application

Figure 1: A typical purchase order form.

where a user is encouraged to browse and choose items he or she would like to purchase. Once the user has chosen the items to be purchased, the total price and the total quantity are computed by the server and a new page with price and quantity details (along with the users chosen item) is shown to the user as shown in Figure 1. A user still has the option to change his order details by changing the quantity of the chosen items.

If a user now tries to update one of the quantities then he is explicitly asked to request the server to update the corresponding details about the total price, discount and so forth. The server essentially re-computes a new total cost and a new total quantity on the basis of changed field quantity and sends a new page to the client with the updated details. Such an approach is highly server-centric and relies heavily on the assumptions:

• that the round-trip to server is relatively fast; and
• that server is available (at all times) to process the client requests.

Moreover, such an approach has other side-effects.

1. The client is annoyed by the delay in response caused due to the round-trip to server which is essentially re-computation of the existing details.
2. The re-computation process leads to less server availability for other incoming requests.

Moreover, the service programmer has to do extra programming to take care of this re-computation and re-show of pages.

These round-trips to the server and the notion of all-time server availability could have been avoided if the the form field relationships were handled at the client itself. But, frequently that is not the case. This could be attributed to the fact that firstly, there is no standard for specifying such relationships and secondly, the handling of relationships on the client side is fraught with inconsistent behaviour due to the non-uniform handling of JavaScript (see Appendix A.1). The advantage of client-side handling of relationships is that it opens up the possibility of auto-completion of unfilled form fields and auto-update of filled form fields without explicitly contacting the server. We also conjecture that such an approach can also be used to give meaningful and precise error messages incrementally, and not when the form is submitted to the server. We have not investigated that in our report but we believe such a thing is feasible.

The simplicity of relationships justifies a purely declarative approach. This is in complete contrast to programming in JavaScript where a programmer is exposed to low-level details and has to think about the order in which these relationships are handled. A high level description of such relationships in a domain-specific language will expose a programmer to only the relevant details. This results in specifications which are easier to read, write and maintain. Further, a high-level approach encourages modular development of the form where a form is designed independently or perhaps generated automatically by a tool and the relationship specifications are later added or even specified separately.

Furthermore, since web browsers do not support JavaScript in a uniform manner (Appendix A.1), the generated code from such relationships must be targeted to a subset of JavaScript that all browsers implement. For many cases this subset is not easy to find even by experienced JavaScript programmers. A tool that automatically translates these high-level descriptions to this common subset is therefore much desired; this means that only the compiler writer is concerned with such an issue.

Additionally, these specifications should be expressible in a XML-like language so as to easily integrate with other XML-tag based form technologies such as Scalable Vector Graphics (SVG) [13] and Synchronised Multimedia Integration Language (SMIL) [14].

We summarise our requirements as:

• the relationship specifications should be declarative;
• the specifications should be expressed in a high-level domain-specific language and should integrate well with XML; and
• the implementation should not be browser dependent.

The rest of this report is organised as described below. Section 2 gives a background on the techniques and concepts involved. Section 3 describes the related work. Section 4 describes the auto-completion mechanism. Section 5 describes some applications of the above formalism. Section 6 describes the various properties of a well-behaved mechanism. Section 7 describes the implementation details. Finally, Section 8 gives an overview of the future work.

We digress here to make explicit the distinction between relationships and constraints in context of a HTML form. A field may be related to other fields by an algebraic binary function as `+' , or it may take the form of an arbitrary n-ary function. On the other hand, a field value can be constrained to take only integer values for example, between 1 and 1000. Thus, constraints are defined at a micro level (on a field value) whereas relationships are defined at a macro level (amongst form field values). In this report, we will intermittently use the term constraints to mean relationships. When we want to imply constraints on field value we will refer constraints as field validation formats or simply field formats.