next up previous
Next: Composite Predicates Up: Auto-completion and Auto-update Mechanism Previous: A Small Example


Modeling Language: Syntax and Semantics

We now describe the various constructs in our language and give a brief description of its intended semantics. We have used the following convention for our grammar namely, `*' indicates zero or more repetitions, `+' indicates one or more repetitions and `|' indicates a choice and attributes enclosed in `[' and `]' are optional. The complete grammar specification is also available in Appendix A.2 for reference.

predicatedef $ \rightarrow$ <predicate id = stringconst>
$ $$ $$ $predicate-body
</predicate>
predicate-body $ \rightarrow$ <body>
$ $$ $$ $argumentlist
$ $$ $$ $checkcode
$ $$ $$ $autocompletionrules
</body>
$ \vert$ <template>
$ $$ $$ $argumentlist
$ $$ $$ $checkcode
$ $$ $$ $autocompletionrules
</template>
$ \vert$ <bind [idref=stringconst] [url=stringconst]>
$ $$ $binding-list$ \sp\ast$
</bind>
$ \vert$ <if>
$ $$ $predicate-expression
$ $$ $$ $<then>predicate-ref</then>
$ $$ $$ $ [<else>predicate-ref</else>]
</if>
predicate-expression $ \rightarrow$ predicate-ref
$ \vert$ <and>
$ $$ $$ $predicate-expression
$ $$ $$ $predicate-expression
</and>
$ \vert$ <or>
$ $$ $$ $predicate-expression
$ $$ $$ $predicate-expression
</or>
$ \vert$ <not>
$ $$ $$ $predicate-expression
</not>
predicate-ref $ \rightarrow$ <predicate idref=stringconst/>

Any auto-completion specification consists of a number of predicate definitions. A predicate can be defined from scratch by defining each of its individual components like argument-list, check-code and auto-completion rules as shown by body element or it be a template for other predicates denoted by template element. The argument-list for a template serves as a placeholder for the template variables. It is possible to deduce an argument-list at compile-time but it is prone to errors. By making the argument-list explicit we can ensure that there are no template variables that remain uninstantiated. The bind element denotes a predicate which is defined by instantiating the referred template (given by idref attribute) and binding the arguments specified in the template's argument-list to concrete HTML form field values . A template can also be stored at a different place and can be accessed over the Internet by specifying url attribute of the bind tag. The predicate can also be formed by supplying appropriate predicate references to the IF-THEN-ELSE construct. We will describe the intended semantics of this construct later in Section 4.4. It suffices to say for the moment that the non-terminal predicate-expression is used to specify boolean expression trees which acts as guards to the auto-completion rules of predicate references given by then and else tags. The predicate-ref element denotes a reference to a predicate by means of idref attribute.

Any predicate is a 3-tuple:

P = ( A, C, $ \cal{A}$)
where, 

 A is a set of fields that form the predicate,


C is the check-code, and

 $ \cal{A}$ is a finite set of rules.

binding-list $ \rightarrow$ <to>
$ $$ $ argument
$ $$ $ assignment
</to>
assignment $ \rightarrow$ <field name=stringconst/>
$ \vert$ <const value= intconst/>
$ \vert$ <interface id=stringconst name=stringconst />
argument $ \rightarrow$ <argument name=stringconst/>
The to element denotes a list of bindings. The field element denotes a field name. The const element denotes a constant value. The interface element denotes a link to another predicate given by id attribute and the name attribute. The argument element denotes a field or a function name.

The template is instantiated by binding the concrete form field values with the arguments in the template's argument-list in a copy of the referred template. Each template binding is a list B= $ B_1$,$ B_2$,...$ B_n$ of pairs:

B = ($ A_1$, $ A_2$)
where, 

 $ A_1$ is a  name of the argument of the template to which $ A_2$ will bind to, and  

 $ A_2$ is a link to another predicate (given byinterface element ), 


or a constant (given by const element)or a named form field

 (given by field).

checkcode $ \rightarrow$ <checkcode>
$ $$ $$ $operator
$ $$ $$ $result
$ $$ $$ $argumentlist
</checkcode>
operator $ \rightarrow$ <operator name =stringconst />
result $ \rightarrow$ <result name =stringconst/>
argumentlist $ \rightarrow$ <argumentlist>
$ $$ $$ $argument$ \sp+$
</argumentlist>
The checkcode element denotes the check-code C for a given predicate. The operator element denotes the function name. The result element denotes the field name and the element argumentlist denotes one or more arguments. The argument nonterminal has already been explained above. A check-code C is a four-tuple:
C = ( $ {\cal M}_c$, $ A_c$, $ f_c$, $ r_c$ )
where, 

 
$ {\cal M}_c$ is a set of known fields required for check-code evaluation,

 $ A_c$ is a list of arguments to the function,

 $ f_c$ is a name of the function, and

 $ r_c$ is a name of the result field.

The semantics of check-code C is that the function $ f_c$ is evaluated with $ A_c$ as the list of arguments. The evaluated value is checked with the value of the result field $ r_c$. If they are the same then check-code returns true and false otherwise. The evaluation $ {\it eval}_c$ of check-code C can be formalised as:

$\displaystyle {\it eval}_c(C) \equiv \left\{\begin{array}{l@{\quad\quad}l} {\i... ...) & \mbox{iff } \forall v \in {\cal M}_c : v \in \mathbb{V}\end{array}\right. $

$\displaystyle {\it apply}_c(f_c, A_c, r_c) \equiv \left\{\begin{array}{l@{\qua... ..._c) = {\it val}(r_c) \\ {\it false} & \mbox{ } otherwise \end{array}\right. $

eval is defined later in section 7. The mode $ {\cal M}_c$ is not a part of the language syntax as it is automatically deduced 1 by the compiler from the argument-list $ A_c$ and the result field $ r_c$.

For primitive predicates, it might seem like redundant information to be carried around but in case of composite predicate such information is necessary as the argument-list $ A_c$ might consist of functions that the compiler generated itself.

autocompletionrules $ \rightarrow$ <autocompletionrules>
$ $$ $autocompletionrules-body
</autocompletionrules>
autocompletionrules-body $ \rightarrow$ <empty/>
$ \vert$ $ $$ $$ $rule$ \sp+$
rule $ \rightarrow$ <rule>
$ $$ $$ $argumentlist
$ $$ $$ $guard
$ $$ $$ $result
$ $$ $$ $operator
</rule>

The autcompletionrules element denotes a set of rules. The rule element denotes an auto-completion rule. In some cases, there may be no rules and is denoted by empty tag. A rule is given by the argumentlist, guard, result and operator nonterminals. Formally, auto-completion rules $ \cal{A}$ is a set of rules: $ \cal{A}$ = $ \{$ $ R_1$, $ R_2$, .....$ R_n$ $ \}$. Each rule R is a five-tuple:

R = ( G, $ {\cal M}_r$, $ f_r$, $ A_r$, $ r_r$)
where, 

 G is a guard for the rule;

 
$ {\cal M}_r$ is a set of known fields needed for rule trigger,

 $ f_r$ is a  name of the function,

 $ A_r$ is a list of arguments to the function, and 

 $ r_r$ is a name of the field that receives the value from rule trigger.
The semantics of rule is that if the guard G is satisfied and mode-rule $ {\cal M}_r$ consists of known fields and the field $ r_r$ is unknown, then a rule trigger can be defined as evaluating function $ f_r$ with $ A_r$ as the argument-list that returns a value to be assigned to the field represented by $ r_r$. A rule trigger $ {\it trigger}_R$ for a rule R can then be defined as:

$ {\it trigger}_R$ $ \equiv$ eval($ f_r$)($ A_r$) iff { $ \forall$ v $ \in$ $ {\cal M}_r$ : v $ \in$ $ \mathbb{V}$ } $ \cap$ $ r_r$ $ \notin$ $ \mathbb{V}$

guard $ \rightarrow$ <guard>
$ $$ $$ $guard-body
</guard>
guard-body $ \rightarrow$ </empty>
$ \vert$ $ $$ $$ $argumentlist
$ $$ $$ $operator

A guard element denotes a guard. The nonterminal operator and argumentlist have already been explained above. A guard G is a three-tuple:

G = ( $ {\cal M}_g$, $ f_g$, $ A_g$)
where, 

 
$ {\cal M}_g$ is a set of known fields needed for guard evaluation,

 $ f_g$ is the name of the function, and 

 $ A_g$ is a list of arguments to the function.

Before a guard G is evaluated, the mode $ {\cal M}_g$ is checked. If the fields are known then the guard is evaluated by evaluating the associated expression tree $ T_G$ and is defined as:

$\displaystyle {\it eval}_g(G) \equiv \left\{\begin{array}{l@{\quad\quad}l} \... ...) & \mbox{iff } \forall v \in {\cal M}_g : v \in \mathbb{V}\end{array}\right. $

Additionally, fields that are read-only are specified by the following syntax:

autoupdate-def $ \rightarrow$ <autoupdate name=stringconst status=stringconst/>

Here, the autoupdate element denotes information about a field whose name is given by name attribute and its status is given by a status attribute. There are instances, as described in Section 4.6 when some additional information also needs to be included for auto-update of fields. That information can be specified as:

metainfo $ \rightarrow$ <metainfo update=stringconst ignore=stringconst/ >

The metainfo element denotes a relationship between two fields given by update and ignore attributes. If a form has very complicated relationships additional JavaScript functions can be included by specifying a file name in which the functions have been coded. The predefined functions are included in the specifications by the following syntax:

include-file $ \rightarrow$ <include name =stringconst/>

where, the include element denotes a file whose name is given by name attribute.

next up previous
Next: Composite Predicates Up: Auto-completion and Auto-update Mechanism Previous: A Small Example
Sunil Kothari 2006-04-29