Examples

Example 1 Purchase Order

We consider again the purchase order form.

<table BORDER COLS=5 WIDTH="80%" >
<tr>
 <td WIDTH="10%">Item No.</td>
 <td WIDTH="30%">Article Description</td>
 <td WIDTH="15%">Quantity</td>
 <td WIDTH="10%">Price per Item</td>
 <td WIDTH="15%">Cost</td>
</tr>

<tr>
 <td>1</td>
 <td>Microsoft Office Suite</td>
 <td><input type="text" name="Q1" value="" size="3"/></td>
 <td>6<input type="hidden" name="P1" value="6"/></td>
 <td><input type="hidden" name="C1" value="" size="5"/></td>
</tr>

<tr>
<td>2</td>
 <td>Microsoft SQL Server</td>
 <td><input type="text" name="Q2" value="" size="3"/></td>
 <td>2<input type="hidden" name="P2" value="2"/></td>
 <td><input type="hidden" name="C2" value="" size="5"/></td>
</tr>

<tr>
 <td>3</td>
 <td>Corel Draw Version 6.0</td>
 <td><input type="text" name="Q3" value="" size="3"/></td>
 <td>7<input type="hidden" name="P3" value="7"/></td>
 <td><input type="hidden" name="C3" value="" size="5"/></td>
</tr>

<tr>
 <td></td>
 <td></td>
 <td>Total Quantity<input type="text" name="TQ" value=""
size="4"/></td>
 <td></td>
 <td>Total Price<input type="text" name="TC" value="" size="7"/></td>
</tr>
</table>
<input type="reset" name="resetbtn" value="Reset"/></form>

We add format specification to the fields namely, all quantities are positive integers and total cost can be positive real number. When the HTML page containing the form is loaded by the browser the form looks as shown in Figure 7.

Figure 7: Purchase order form with validation and auto-completion.

The auto-complete specification is shown below. The following code fragment shows how a template for a primitive predicate that models the relationship C = A + B is defined:

< predicate  id="predicateplus">
< template>
   < argumentlist>
       < argument name ="A" />
       < argument name ="B" />
       < argument name ="C" />
   </ argumentlist>  
   < checkcode>
     < operator name="plus"/>
     < result name="C"/>
     < argumentlist>
          < argument name="A"/>
          < argument name="B"/>
      </ argumentlist>
   </ checkcode>
   < autocompletionrules>
      < rule>
         < argumentlist>
           < argument name="A" />
           < argument name="B" />
         </ argumentlist>                        
         < guard>
           < empty/>
         </ guard>
         < result name="C" />
         < operator name="plus"/>
     </ rule>
     < rule>
         < argumentlist>
         < argument name="C" />
         < argument name="B" />
       </ argumentlist>
       < guard>
         < empty/>
       </ guard>
       < result name="A"/>
       < operator name="minus"/>
     </ rule>
     < rule>
        < argumentlist>
           < argument name="C" />
           < argument name="A" />
        </ argumentlist>
        < guard>
          < empty/>
        </ guard>
        < result name="B"/>
        < operator name="minus"/>
      </ rule>
     </ autocompletionrules>
   </ template>
  </ predicate>

The "plus" and "minus" are calls to predefined JavaScript functions. We defer the details about how these functions are called till Section 7. A template is instantiated by binding concrete form fields to the arguments of the argument-list as shown below:

  < predicate id="predicate5">
  < bind idref="predicateplus">
   < to>
     < argument name="A"/>
     < field name="Q1"/>
   </ to>
   < to>
     < argument name ="B"/>
     < field name ="Q2"/>
   </ to>
   < to>
     < argument name ="C"/>
     < interface id="predicate6" name="A"/>
   </ to>
 </ bind>
</ predicate>

< predicate id="predicate6">
  < bind idref="predicateplus">
   < to>
     < argument name="A"/>
     < interface id="predicate5" name="C"/>
   </ to>
   < to>
     < argument name="B"/>
     < field name ="Q3"/>
   </ to>
   < to>
     < argument name ="C"/>
     < field name = "TQ"/>
   </ to>
 </ bind>
</ predicate>

The code above models a relationship of the form Q1 + Q2 + Q3 = TQ where Q1, Q2, Q3 are the three quantities above and TQ denote the total quantity as shown in Figure 7. Note the use of interfaces to capture intermediate values. A form designer can also make certain fields as read-only; specifically, fields which derive their values from other field values. In this example the total quantity and the total cost are deduced quantities and these fields are specified as read-only as shown below:

< autoupdate name="TC" status="forbidden"/>
< autoupdate name="TQ" status="forbidden"/>

The field formats for field Q1 can be specified as:

  < regexp id="digit">
     < charrange low ="0" high="9"/>
   </ regexp>
   
   < regexp id ="intnumber">
    < plus> < regexp idref="digit"/></ plus>
  </ regexp>

   < constraint  field="Q1">
    < regexp idref="intnumber"/>
  </ constraint>

This example also highlights the seamless integration of field formats and auto-completion in such a manner that an auto-completed value is also a valid field value.

Example 2 Decision Tree

We take another example to show how primitive predicates can be used to compose higher-order predicates. Consider a HTML form where a user can enter three numbers and the smallest number is automatically deduced from the given information and assigned to a fourth field. A code fragment of the HTML form is shown below:

<form>Decision Tree
<table BORDER COLS=3 WIDTH="50%" >
<tr>
  <td>Number 1</td>
  <td>Number 2</td>
  <td>Number 3</td>
</tr>
<tr>
 <td><input type="text" name="N1" size="5"/></td>
 <td><input type="text" name="N2" size="5"/></td>
 <td><input type="text" name="N3" size="5"/></td>
</tr>
<tr>
<td></td>
<td>The smallest number</td>
<td><input type="text" name="N4" size="5"/></td>
</tr>
</table>
</form>

This problem can be formulated with a number of primitive and composed predicates as shown below:

1.< predicate id="predicate6">
2. < if>
3.   < predicate idref="predicate1"/>
4.     < then>< predicate idref="predicate5"/></ then>
5.     < else>< predicate idref="predicate4"/></ else>
6.  </ if>
7.</ predicate>
8.< predicate id="predicate7">
9.  < if>
10.   < predicate idref="predicate2"/>
11.      < then>< predicate idref="predicate3"/></ then>
12.      < else>< predicate idref="predicate5"/></ else>
13.  </ if>
14.</ predicate>
15. < predicate id="predicate8">
16.  < if>
17.   < predicate idref="predicate0"/>
18.      < then>< predicate idref="predicate6"/></ then>
19.      < else>< predicate idref="predicate7"/></ else>
20.  </ if>
21.</ predicate>

Table 1: Predicates Ids and Corresponding Relationships

PredicateId	Relationships
Predicate0	N1 $\rangle$ N2
Predicate1	N2 $\rangle$ N3
Predicate2	N3 $\rangle$ N1
Predicate3	N1 = N4
Predicate4	N2 = N4
Predicate5	N3 = N4

The compiler flags all the predicates that are used to built composite predicates. A transitive closure of dependency of composite predicates yields that last predicate is an un-flagged predicate. Hence only the last predicate (predicate8) will have rule triggers. All the predicates and the corresponding relationships they model are shown in Table 1. The resultant predicate has 8 auto-completion rules of which 4 are never triggered because the guard-mode contains a field which is the result of rule trigger.

Figure 8: Finding smallest of 3 numbers: Auto-completion mode.

Figure 8 shows how the smallest number field is auto-completed when the three numbers are known. Note the value deduced conforms to the field format as shown by the green light.

Figure 9: Finding smallest of 3 numbers: Auto-update mode.

Figure 9 shows how the smallest number field changes when the second number is updated.

Example 3 2002 FIFA World Cup

To show that our approach is correct for other named form fields we have tried to model 2002 FIFA World Cup [16] where the entire process of choosing a winner from 32 teams that qualify for the final stage of the tournament is modelled as a single HTML form. This example is demonstrative of what can be done when relationships are very domain-specific.

The final stage of the tournament is played in two rounds: First round and Second round. In the first round, the teams are divided into 8 groups of 4 teams each. The teams play against each other in a round-robin fashion i.e. a team plays with 3 other teams in the same group. Any particular group has six matches in all. The winner and the runners-up from each group qualify for round two. A section of the form that models first round is shown in Figure 10. A user can specify the scores of different matches to see who wins the match. But, since there are 32 teams, it becomes very tedious to specify scores for each and every match. To this end, we have given every match a default score which also reflects the actual match results and can be verified at FIFA World Cup 2002 web site.

Figure 10: The preliminary round where teams compete in a round-robin fashion.

The second round consists of a number of phases: round of 16, quarter finals, semi finals and finals in that order. In this round, teams play in a knock-out fashion; only the winner qualifies for the next phase. A section of the HTML form that models the Quarter finals and Semifinal phase is shown in Figure 11

Figure 11: The round two where teams compete in a knock-out fashion.

The appendix A.3 describes the the criteria for winners from different rounds. After each round half of the teams are eliminated. So, at the start there are 32 teams, after this round there are 16 teams and so forth till a winner emerges. A user can enter the scores of the individual matches but he cannot choose the teams that qualify for the next stage of the tournament even though an individual team is shown by a drop-down box. as shown in figure 10.

When the form is first loaded and since the match score have been supplied as default values the winner is calculated from the match scores. It is important to note that any team could be a winner out of the 32 teams which means that winners in each stage of the tournament could be any of the 32 teams as shown in Figure 11.

A programmer can specify these fields as read-only as they are deduced from the score entered by the user. Due to the deficiency in the design of the singular select the compiler inserts an err option if none of the options is selected. A singular select by default chooses the first option as selected if none is specified. With this annotation, we can now differentiate whether the first option is selected by default or not.

This example also highlights the limitations of PowerForms existing syntax of modelling field dependencies. We wrote almost 4000 lines of code in the existing PowerForms syntax for modelling field interdependencies only to realise that existing formulation is not expressive enough to model such complex relationships. The include-file element described in our grammar takes care of such scenarios where the existing library is unable to support these very domain specific functions. The correctness of our approach then assumes that a programmer will code these functions in the common subset of JavaScript that we earlier mentioned.

Here again, when the form is first loaded the mechanism is run in auto-completion mode and later when fields are updated it is run in auto-update mode. In each case, a fixed-point is demonstrated by a unique winner that emerges at the end of the computation. For the default case, when no field value is entered by the user, the winner is shown in Figure 12.

Figure 12: A section of the form showing the final winner.

Example 4 Temperature Conversion

A final example deals with the idea of aggressive auto-completion. Here, we model a celsius-fahrenheit conversion. Consider a form that models this conversion as shown below:

<form >
Celsius Fahrenheit Conversion
<table BORDER COLS=3 WIDTH="50%"/>
 <tr>
  <td>celsius</td>
  <td>fahrenheit</td>
 </tr>
 <tr>
   <td><input type="text" name="celsius"/></td>
   <td><input type="text" name="fahrenheit"/></td>
 </tr>
</table>
</form>

This conversion can be modelled by a number of predicates which model addition and multiplication. As an aid to form designer, our tool has a mechanism that allows a form designer to store and later retrieve the stored templates by specifying the URL as shown in the following specification:

  <predicate  id="predicate0" >
   < bind
url="http://www.brics.dk/~sunil/worldcupcon/predicateplus">
     < to>
        < argument name = "C"/>
        < field name = "fahrenheit"/>
     </ to>
     < to>
       < argument name = "B"/>
       < const  value = "32"/>
     </ to>
     < to>
       < argument name ="A"/>
       < interface id ="predicate1" name ="A"/>
     </ to>
  </ bind>
 </ predicate>

< predicate  id="predicate1">
   < bind url
="http://www.brics.dk/~sunil/worldcupcon/predicatemultiply">
     < to>
        < argument name ="C"/>
        < interface id = "predicate2" name="C"/>
     </ to>
     < to>
       < argument name ="B"/>
       < const value ="5"/>
     </ to>
     < to>
       < argument name ="A"/>
       < interface id ="predicate0" name="A"/>
     </ to>    
  </ bind>
 </ predicate>

< predicate  id="predicate2">
   < bind
url="http://www.brics.dk/~sunil/worldcupcon/predicatemultiply">
     < to>
        < argument name ="C"/>
        < interface id ="predicate1" name="C"/>
     </ to>
     < to>
       < argument name ="B"/>
       < const value ="9"/>
     </ to>
     < to>
       < argument name ="A"/>
       < field name ="celsius"/>
     </ to>    
  </ bind>
 </ predicate>

When the browser loads the page, both the fields are empty. A user then inputs 60 as the celsius field value.The fahrenheit is computed and gets the value 140 as shown in Figure 13. However, when a user modifies fahrenheit field we want that the celsius field should reflect the corresponding value.

Figure 13: Auto-completion conversion when both fields are empty.

Clearly, our specification above and the algorithm for auto-completion will not produce the desired effect since the celsius field is already known. We require additional information as given below:

     < metainfo update="celsius" ignore="fahrenheit"/>
     < metainfo update="fahrenheit" ignore="celsius"/>
   

If a user then modifies the deduced fahrenheit field value to 14, a corresponding value now appears in celsius field as shown in Figure 14. This is an instance of aggressive auto-completion wherein, overwriting of values is allowed. When a field update is detected, the algorithm uses this additional information to decide which field values to ignore in the repository.

Figure 14: An instance of aggressive auto-competion.