W3C [1] has proposed XForms [6] as the next generation of web forms. The central idea in XForms is to separate purpose from the presentation of the form. XForms relies on the abstraction of form to two distinct areas :
The ref attribute specifies that the input data should be bound to a node price in instance data. The output tag refers to the fact that price is read-only.
We discuss the approach taken by Honkala and Boyer [12] and discuss their implementation of XForms. Their implementation is important because it gives a comprehensive view of how computational relationships between the form fields can be used to do auto-updates especially in context of XForms. We ignore the specific technical details regarding other Xforms features but focus on the xforms-recalculate event [4]. Briefly, a recalculate event is triggered when a user changes an instance data. First, we define some terminologies that we will use later. The underlying notion of relationships in XForms is expressed as a graph : Master Dependency Directed graph and Pertinent Dependency subgraph.
A Master Dependency graph M is a directed graph consists of a set of vertices V and a set of edges E that represent the computational dependencies between vertices. It is constructed when the page is first loaded in the browser and remains unchanged till the browser eventually unloads the page.
A Pertinent Dependency Graph is obtained from master graph and is invoked when the recalculation algorithm detects a change in instance nodes and is obtained by exploring the paths of edges and vertices that are reachable from the changed vertex.
The implementation by Honkala and Boyer makes explicit use of topological sorting (to determine which field values will be calculated next ) in implementing the recalculation algorithm. Also, they rely heavily on the notion that it is possible to deduce Pertinent graph from a Master graph whenever a user modifies a field. Since XForms uses XPath expressions to access the instance data, their implementation suffers from the limitations of XPath itself. For example, XForms forbids use of XPath constructs that result in a change of node-set reference within a XPath expression based on any changes to the instance data. Also, for very complex forms, building of a pertinent graph, every time a user inputs data, is a time intensive operation and may not lead to instantaneous updates. Moreover, Xforms requires a Xforms processor on the client.
In contrast, our approach uses a simple rule-based formalism where the dependencies between the various relationships are settled through a fixed-point process. Such an approach obviates the need for maintaining explicit information about the dependencies and doing a topological sort every time a field is changed. Further, our formalism is more expressive as it can handle if-then-else kind of relationships. The explicit use of guards gives a very clean semantics to if-then-else construct in our language.
Abdualrraouf and Ridley [21] have suggested a way of disallowing certain form field values for forms which collect information that is stored in a database. They conjecture that meta information stored in a database system can be extracted in a useful manner and then used to restrict values in form fields that violate this meta information. Clearly, their work targets a very small subset of HTML forms. Moreover, their work is still at a conceptual stage and lacks a full implementation.
Another implementation of client-side handling of form field relationships in XML is XFDL, extensible form description language [29]. The implementation lacks declarative specifications and a programmer has to specify exactly what should happen when some field is given a input. Moreover, their implementation is rigid and requires platform specific browsers that support Java runtime environment.
To the best of our knowledge, no one has worked before on auto-completion of and auto-update of HTML form fields using a fixed-point approach of satisfying relationships.