Forms offer a structured interface to users for entering or editing information which is eventually submitted to some system for further processing. Forms play a crucial role on the Web. Early form technology enables interactivity on the Web beyond hyperlinking: With forms in a Web browser, users can activate services on the Web, after setting service parameters, and they will receive service results in the browser in a request-response cycle. Another use case is data entry, with forms in a Web browser acting as masks for database input. Recently, Sperberg-McQueen in personal discussion and workshop announcements has framed forms on the Web as padded-cell editors that allow for specialized editing of XML documents and data in a Web browser in a safe and easy-to-learn manner.
How has forms technology for the Web evolved over time? There are two lines of development:
The HTML strain has focused on the user interface. The forms module of HTML defines a set of widget or control elements; an HTML form contains a number of widgets and a target URL to which form data are to be submitted. HTML browsers display form widgets, support data entry and encode form data, transferring them to the form's target URL when submission of a form is activated.
The most recent version of HTML, namely HTML5, has expanded the set of widgets and has added type definitions to form elements, enabling native in-form data validation.
The XForms strain has brought data into focus. XForms separates the data of a form from its user interface; form data in XForms are XML documents that can be loaded into a form, edited via widgets and submitted to external services. An XForms processor supports the binding between a form's widgets and data, handles form events and executes form actions including load and submit of data.
The remainder of this paper is organized as follows: First, we derive the requirements for an XForms processor from the core features of XForms in section “Requirements for an XForms processor”. Since our target implementation platforms are Web browsers, we relate XForms features and XForms processor requirements to HTML forms.
In section “XForms building blocks on a Web browser” we discuss which building blocks an HTML5-enabled Web browser does or does not provide, in view of our requirements.
Finally, we discuss in section “The XForms processor xf.js” core principles, architecture and limitations of our implementation, illustrated with examples and screenshots.
Requirements for an XForms processor
Form systems share core functionality: A form offers a structured interface to users for entering or editing information which may then be further processed outside the form. In the realm of the Web, HTML has enabled data capture and interactivity beyond hyperlinking via forms since version 2. As its name implies, XForms leverages XML and related technologies. XForms extends HTML forms in providing essential innovations (cf. XFormsEssentials):
Data model: An XForms form holds its data in an explicitly defined, XML encoded data container, which is called the form's data model. A key point of XForms is that a form's data model is independent of its user interface.
Data types: Textual values in the data model can be declared to be of specific data types; XML Schema's predefined or user-defined data types (simple types) may be used.
Events: XForms builds on the W3C Recommendation XML Events. Form events, their targets and associated actions are declaratively represented by XML elements and attributes.
Widgets: XForms defines a rich set of widgets that has only recently been matched by the newest version of HTML, namely HTML5.
Repetitions: XForms has a number of container form controls, for repetitions, groupings and switching. XForms is the only forms technology on the Web that natively supports repeating groups of widgets under action control.
These innovations, whose value is discussed elsewhere XForms 1.1XFormsEssentialsFormsNG imply requirements for any XForms processor. We discuss these implications in detail below, contrasting them with the lesser requirements of HTML forms.
Form systems deal with data that initialize a form, are edited using the form and are eventually submitted to external systems for further processing.
XForms distinguishes between a data model, which carries the form's information, and the user interface, which makes the data model accessible to an XForms user. On submission, the data model (or a part of it) is transferred to an external service. The data model itself is encoded in XML. It can be seen as a structure of nodes carrying data (text nodes and attribute nodes in the XDM data model for XML).
XForms facilitates editing of data in the model in two alternative ways: The obvious first possibility is to use widget elements that are connected to nodes in the data model. Changing a widget's value in the user interface changes the value of the corresponding node in the model. The XForms processor propagates value changes to all widgets that might be connected to the same node, in Model-View-Controller fashion. The second and less obvious possibility to change the data model is by action elements which act as event handlers for form events. An action element is connected to a node (or a set of nodes) in the data model in the same way as a widget element. In both cases the connection to a node in the model, called a reference, is expressed by an XPath expression.
In contrast, HTML forms do not have explicit, separate data models. The model of an HTML form is implicitly defined by the widget elements in the form. It is a flat set of name-value pairs, implicitly ordered by the sequence of the widgets in the form. The model is generated on the fly when the form is submitted.
Hence, HTML forms do not separate data and input facilities the way XForms does. In addition, further processing of form data that originate from an HTML form usually necessitates data translation, whereas XForms data can be directly processed using XML technologies as in the zero-translation XRX architecture.
It is immediately apparent that an XForms processor needs to support building, changing and serializing of XML structures and dynamic evaluation of XPath expressions.
Data types and data model validation
Form systems that support data types can offer type-specific data entry support such as date pickers and data validation without custom scripting. XForms offers a small number of proprietary data types and supports the built-in simple types of XML Schema. On top of that, the data model of a form can be constrained by an external schema with XML Schema custom data types (simple types) and also complex types. This ensures that not only updates to data values but also changes in the structure of the data model via actions are schema conformant.
Earlier versions of HTML forms did not provide type support. All data values were considered as text, for which custom validation rules could be scripted. HTML5 knows a small number of pre-defined data types, which can be customized declaratively by a few parameters and regular expressions, similar to restricting XML Schema simple types with facets. HTML5 data types are validated in conformant browsers. This is the big advantage of HTML5 over earlier versions of HTML with respect to forms.
A fully conformant XForms processor must be able to do XML Schema validation dynamically, also selectively for parts of the document.
Form systems handle events or signals that are activated in a form internally or under user control. For example, events can cause parts of a form to expand or collapse or value changes to be propagated to formulas that need to be re-evaluated, spreadsheet-like.
As to events, both HTML forms and XForms are based on the DOM Events W3C Recommendation. DOM Events defines the structure of and processing rules for browser events. XForms goes beyond HTML forms in that it utilizes an XML encoding layer for DOM events, according to the W3C Recommendation XML Events.
A form reacts to an event by executing an action. In HTML forms, actions are
events by HTML-specific attributes (such as
onclick) or by registration
mechanisms that are specific to the scripting language in use. In contrast, XForms
has predefined actions (such as
delete). XForms also specifies events beyond DOM Events. Most
importantly, it uses the standardized XML encoding of XML Events to associate events
with actions. XML Events defines how to encode event-related information in XML.
With XML Events and XForms' predefined actions, the processing of specific events
can be defined declaratively, reducing the need for scripting.
Consequently, an XForms processor needs to implement the predefined XForms actions and specific XForms events, and it must be able to interprete XML Event definitions, in addition to supporting DOM events and their processing model.
The most prominent feature of a form system is the set of widgets that is available for data entry. In this respect, XForms and HTML5 are basically equivalent, while earlier versions of HTML are slightly weaker [Pemberton 2003].
Forms need to display repeated data that can be manipulated with actions, such as
repeating rows in a database table view. XForms provides the user-interface element
repeat, which contains a template of inner widgets that will be
instantiated for each portion of the block of data in the form's data that the
repeat is connected with. Early versions of HTML do not support
repetitions natively. Interestingly enough, repetition functionality has been a part
of Webforms 2, a tributary to HTML5 that has been inspired by XForms, but has not made
it into HTML5. Hence, no version of HTML forms supports repetitions, but XForms
processors must support the
To summarize, an XForms processor needs to satisfy the following requirements beyond those of a simple HTML forms processor:
Handling of XML data, including load and transmit.
Dynamic evaluation of XPath expressions.
Dynamic evaluation of (parts of) XML data against XML Schema.
Support for XForms widgets.
Support for the
Implementation of XForms actions.
Support for XForms events.
Interpretation of XML Event definitions.
XForms building blocks on a Web browser
The implementation platform for our XForms processor xf.js is the HTML5-enabled browser. Referring back to the requirements for an XForms processor, we discuss in this section, which building blocks of an XForms processor an HTML5-enabled browser provides and what needs to be built in xf.js from scratch.
With Document Object Model (DOM) Level 3 XPath Specification, W3C defines an interface to query a DOM object with an XPath 1.0 expression. The interface provides, among others, the following two methods:
evaluate()evaluates an XPath expression against a DOM node.
createNSResolver()generates a namespace resolver object for all namespace definitions that are in scope at a specific DOM node.
XML Events and XML Schema
Current Web browsers support neither XML Events nor XML Schema.
Documents and XML submission
Widgets in XForms and HTML5 have the same functional range but different names. Thus, an XForms processor can utilize HTML5 widgets after mapping, as shown in the following table. It can also utilize the data entry support and validation facilities of an HTML5-enabled browser, compensating at least partially for lacking XML Schema support.
|At default the XForms input widget
enables free-form data entry(cf. XForms 1.1). The same is provided in HTML5 when the type attribute is not set or set to text.
|In HTML5: The type attribute on the
|In HTML5: The type attribute has to be set to submit.|
|In HTML5: The type attribute has to be set to password.|
|In HTML5: The type attribute has to be set to file. But see restrictions in xf.js below.|
|This is the only widget that needs HTML5 beyond earlier HTML versions.
In HTML5: The type attribute has to be set to range. The values of additional attributes can be mapped
|In HTML5: The type attribute has to be set to radio. In XForms there is one
|In HTML5: The size attribute has to be set to a value greater than "1". A browser will display it as a listbox.|
|In HTML5: The size attribute has to be set to "1". A browser will display it as a drop down selection box.|
|In HTML5: The type attribute has to be set to checkbox. In XForms there is one
|In HTML5: The size attribute has to be set to a value greater than "1". Additional the multiple attribute has to be set.|
|In HTML5: The size attribute has to be set "1". Additional the multiple attribute has to be set.|
HTML5-enabled browsers have no native support for repetitions in forms.
In conclusion, on the positive side, HTML5-enabled Web browsers have a good support for XML via the DOM interface. An XML document is made accessible through a DOM interface and nodes in the DOM can be accessed using XPath expressions. New DOM document objects can be created and edited. Browsers also provide widget elements which cover the functionality required by XForms.
On the negative side, even HTML5-enabled Web browsers do not support XML Events nor XML Schema nor repetitions in the user interface. An XForms processor running on the HTML5-enabled bowser platform either has to implement its own support for these technologies or has to neglect them, giving up some required functionality.
The XForms processor xf.js
As the goal was to discover browser capabilities, an easy to handle architecture
was chosen. The xf.js processor implements a class for every supported XForms
element (except the
label element). These classes provide methods and
class members for the specified attributes of the corresponding XForms element. When
an object is instantiated, these members are initialized with the default values
according to the XForms specification.
As Web browsers do not know the semantics of XForms widget elements, the DOM nodes of these elements are replaced by their HTML5 counterparts as shown in Table I.
The initialization of all objects, their relationships and the replacement of the widgets is done in a general parsing function, which is called after the browser has finished loading the document.
The following section introduces the architecture of the xf.js processor by introducing the class model.
The following image shows the underlaying class model of the xf.js processor. For simplicity the classes in the image do not contain method identifiers.
Figure 1: The class model of the xf.js processor
The functionality of the more important classes is described in the following sections.
The core of the processor is the xfModel object which belongs to a
model element in the document. The object has connections to
all objects of elements which are related to the
model node in the
document. This relations can be expressed in different ways. Child elements of
model element are related in a direct way (e.g.
bind). Widget and action elements can
point to a
model element by usage of the model attribute which contains the ID of a corresponding
model element. Finally Widget and action elements can be
implicit related to the first
model element defined in the
document, if they have no model attribute defined.
The xfModel class holds a reference to the DOM node of the corresponding
model element and to the HTML5
form element which
is generated during the parsing process.
The class also provides methods for operations on the model. The most
important method is evaluate(), a central interface to evaluate XPath
expressions concerning the data models hold by dedicated
elements. XForms augments the XPath specification with its own functions. These
XForms specific functions are of course not provided by the Web browser's XPath
interface. Thus the xf.js processor has to handle them by itself and can not
pass it through. Therefore a central evaluation method provides a good place to
implement these additional XForms functions. The processor supports the
additional functions instance() and index(). The evaluation method is also a
well fitting place for another XPath related feature which is still not
implemented: the implicit data model. If a node in the data model is referenced,
which does not exist, it is created by the XForms processor according to the
specification. The XPath interface of Web browsers does not provide such
functionality. But the evaluate method of xfModel could easily provide this
feature. If a XPath evaluation does not return any value, the next step should
be to check on every part of that expression if a corresponding node exists. If
this is not the case, the corresponding node could be generated by using the DOM
For each xfModel object an HTML5
form element is created in the
document. This form is an anchor to all HTML5 widgets which are created to
replace the XForms widget elements. Each xfModel object holds a reference to its
The xfInstance class is used to handle
instance elements which
carry the data model of a form. In the processor one xfInstance object is
generated for every
instance element. At the current state of the
implementation each xfInstance object holds a reference to the DOM node of the
instance element to perform read and write operations on the
data model. The XForms specification requests to handle all data models as
independent documents. Thus operations should not take place in the main
document itself. This feature would also be possible in a Web browser based
XForms implementation, as browsers implement the createDocument() interface as
defined in DOM Level 3 specification. Thus a new XML document could be created and filled with the nodes
defined inside the instance node. The xfInstance class provides also methods to
serialize the data model. For the submission of the data model as XML, the
implementation utilizes the XMLSerializer to generate a XML string. For submission as name-value pairs the
getDataAsHashMap() method flattens the model data down as specified by XForms
xfSubmission and xfWidgetSubmit
A xfSubmission object is responsible for the transmission of a data model. Each xfSubmission object is bidirectional attached to one xfModel object and thus has indirect access to the xfInstance objects holding the data to send. The main method is doSubmit() which performs the submission according to the parameters set. A data model can be submitted as XML document, or as name-value pairs according to HTML forms. The submission can be done using the methods POST, GET, PUT, DELETE or URLENCODED-POST as defined by XForms. To control which part of a data model should be submitted and which one should be replaced the processor implements the attributes ref, replace and targetref.
To start a submission a xfWidgetSubmit object is needed which is connected to
a xfSubmission object. The object is created for a XForms
element and represented to the user as HTML5 button. When the user clicks the
button, the event of that click is handled at the xfWidgetSubmit object which
calls the doSubmit() method of the connected xfSubmission object.
The xfBind class represents the XForms
bind element. As XML
Schema is not supported by browsers (and not implemented in the processor
neither) xfBind allows type checking based on the HTML5 form check interface.
The type attribute can be set to one of the
following values as defined in HTML5: text,
number, url, email, tel, date, time, datetime,
datetime-local, month, week or color.
If a XForms input widget refers to a
bind element with one of
these type values, the type attribute of the
generated HTML5 widget replacing the XForms widget will be set to this value
leading to a deeper integration of XForms into HTML5. Before a data model is
submitted, a check of the user input is done according to the type settings by
usage of the checkValidity interface which was introduced in HTML5 on the
For every XForms widget element an appropriate xfWidget object is created,
e.g. a xfWidgetTrigger object for a
trigger element. As the browser
does not know the semantics of the XForms widget elements they are replaced by
their HTML5 counterparts according to Table I. Every
xfWidget object holds a reference to the corresponding HTML5 widget.
To ensure a widget shows the actual value of the referenced node in the data
model, the processor uses the
Mutation observer interface. The Mutation observer is going to be introduced in DOM 4
to replace the DOM Mutation Events. Every xfWidget object owns a mutation
observer and a callback function which is executed by the observer. The observer
is set to the referenced node in the data model and the callback function
updates the widgets state to the current value of the node in the data
For simplicity the XForms label element is not handled as a own class. As a
label element belongs to another widget element, the label's value is stored as
attribute in the corresponding xfWidget object. Depending on the widget element
the label's value is displayed as HTML5
label element, or on the
widget element itself, e.g. as caption of a button.
xfRepeat and xfRepeatGroup
XForms provides the
repeat element to display all child elements
inside it multiple times. This functionality is given in the processor with the
xfRepeat and xfRepeatGroup classes. The xfRepeat class represents the repeat
repeat element refers to a nodeset in a data model. For every
node in this set the elements inside the
repeat element will be
repeated. The xfRepeatGroup object is used to represent such a repeat. It
contains a copy of all elements which are defined inside the
element of the superior xfRepeat object. Every xfRepeatGroup object also refers
to one node of the repeat element's nodeset.
The processor supports the add and remove operations of such groups. When a new node is added to the nodeset, a new group is created and displayed. When a node is removed from the nodeset, the corresponding group is deleted and removed from the user interface.
Actions and events
The processor supports the action elements
message and the
action to group the others. Each element is
represented by a xfAction class, e.g. xfActionMessage. Each object owns a class
member event which contains the name of the
event on which the object should react. In addition each object has a method
perform() which implements the desired actions.
As Action elements belong to another XForms element, each xf class is able to hold references to one or more action objects. Each xf class also implements a method handleEvent(), a generic event handler for the underlying XForms element. When an event reaches the XForms element, the event handler is called which compares the event's name with the event name of each registered xfAction object. If the names match, the perform() method of the corresponding xfAction object is called.
As we have demonstrated, most of the XForms concepts can be implemented in a browser native XForms processor. But some concepts can not be covered. The restrictions can be divided into the following classes:
Missing technology in an HTML5-enabled Web browser.
Limitations of the platform (browsers and HTML5).
First of all, XML Schema support is missing completely as Web browsers today
do not implement it. A solution for a browser based XForms processor would be to
The same holds for the support of XML Events. Mozilla seems to have had a XML Events implementation but it was rejected from core in 2012. Therefore a XForms processor also has to implement the XML Events specification itself. The xf.js processor partially implements XML Events itself.
Limitations of the platform
To evaluate an XPath expression, a namespace resolver is needed which provides a mapping from namespace prefixes to their corresponding name. A namespace resolver can be build manually or by using the createNSResolver() method. It takes a DOM node n and builds a resolver which knows the namespaces and prefixes of all nodes from the document's root to the given node n. It is not possible to automatically generate a namespace resolver which knows the namespaces of the whole document (and not just a part of it). For the processor implementation this rises the question which node should be taken? It should be a node, at a very deep position in the document tree (to get as much namespace definitions as possible) and on a branch which will be evaluated by the XPath expression in the next step. But such a node can not be chosen without evaluating the XPath expression first. Therefore only the node of the instance element itself (or its first and only child node) can be taken as input for the createNSResolver function. This leads to the problem, that namespaces which are defined inside the data model can not be used and evaluating a XPath expression which contains such namespace prefixes will fail.
Another limitation is given at the document submission. XForms specifies both: synchronous and asynchronous submissions, whereas a synchronous submission means that the document holding the XForms is replaced by the server response. To provide the submission of XML data, the processor has to use the XMLHttpRequest interface. The interface is well suited for asynchronous data transfer (meaning that the document remains in the browser after a submit). But it does not provide functionality to replace the whole document with a server response.
Second, Web browsers prevent scripts from accessing other sites (with different host name, port, etc.). Thus the submission of data to an URL different from the one the current loaded document is not possible for security reasons.
The xf.js processor uses a straight forward architecture. Each XForms element is represented by a corresponding object. After loading the document, a parser instantiates the needed objects and connects them in the desired way. In a second step each widget element is replaced by its HTML5 counterpart.
The xf.js processor supports multiple
model elements in a document and
multiple instances inside a
model element. Nodes in the data model can
either be referenced directly with a XPath expression by using the appropriate attribute
(ref or nodeset)
or by using
bind elements in the data model. A data model can be submitted
as XML or as name-value pairs according to form submission in HTML.
For this purposes the xf.js processor supports the following elements:
submission. For the user interface, the elements
repeat are supported. To show the capabilities of Web browsers towards
events, the xf.js processor implements the Action elements
message and the element
action itself to group multiple other Action elements. These elements
can react on events generated by the Web browser (implementation currently supports
DOMActivate) and on XForms specific events
(xforms-ready is implemented), which are generated
by the processor itself.
To validate user inputs the xf.js processor uses some of the types defined by HTML5,
e.g. number, text,
datetime, etc. These types can be used with a
bind element, like XML Schema types in other processors.
As already mentioned, the xf.js processor has an easy to implement architecture where each supported XForms element is represented as a class. Such a class is instantiated for every XForms element used in a document. The members of the objects are filled with the values given in the element attributes. This architecture has the draw back of creating a shadow model of all information which are already present in the loaded document and accessible via the DOM.
Therefore a new version of the processor is going to be implemented with a different
architecture. Instead of creating an object for every XForms node in the DOM the
existing DOM nodes should be used directly. This includes the enhancement of the DOM
every node. E.g. the DOM node of a XForms
message element node gets a
function perform() associated which displays the defined message to the user when
We plan to make the source code of the new version public as soon as it has reached some kind of maturity.
Appendix A. Examples and screenshots
Finally we want to show the results of the implementation with a set of examples and screenshots. The XForms source is given on each example.
The first example shows how the document is modified when the XForms widget elements are replaced by HTML5 widgets.
This XForms code:
<body> <xf:input ref="data"> <xf:label>Input: </xf:label> </xf:input> <br /> <xf:output value="data"> <xf:label>Result: </xf:label> </xf:output> </body>Will result in the following XHTML5 code:
<body> <label>Input: </label> <input type="text" name="FNinput_Input" value="Back to the Future" form="FN_model1" /> <br /> <label>Output: </label> <output name="output" form="FN_model1">Back to the Future</output> <form id="FN_model1"></form> </body>
It will be displayed as follows:
Figure 2: The user interface in the browser
Changes in the data model
The data model can be changed using widget elements as in the previous example or using action elements. The following shows the XForms code to set a value in the data model after the user has clicked on a button:
<head> ... <xf:model id="model2"> <xf:instance> <timeTravellers xmlns=""> <name>Marty McFly</name> <name>Dr. Emmet Brown</name> <name>Jennifer Parker</name> </timeTravellers> </xf:instance> <xf:instance id="inst2"> <timeMachine xmlns=""> <name></name> </timeMachine> </xf:instance> </xf:model> </head> <body> <xf:trigger> <xf:label>Click me</xf:label> <xf:setvalue ev:event="DOMActivate" ref="instance('inst2')/name" model="model2">DeLorean DMC-12</xf:setvalue> </xf:trigger> <br /> <xf:output ref="instance('inst2')/name" model="model2"> <xf:label>Time machine: </xf:label> </xf:output> </body>This code will lead to the following behaviour in the browser:
Figure 3: Updating the data model with events: Before the click
Figure 4: Updating the data model with events: After the click
The xf.js processor also provides support for the XForms
element. We use the following XForms code as
<body> <div> <xf:repeat id="carRepeat" nodeset="car"> <xf:input ref="."> <xf:label>Car </xf:label> </xf:input> <br /> </xf:repeat> <xf:trigger> <xf:label>Insert new car at beginning</xf:label> <xf:action ev:event="DOMActivate"> <xf:insert nodeset="car" at="1" position="before"/> <xf:setvalue ref="car/text()">Porsche</xf:setvalue> </xf:action> </xf:trigger> <xf:trigger> <xf:label>Delete last car</xf:label> <xf:delete ev:event="DOMActivate" nodeset="car" at="last()"/> </xf:trigger> </div> </body>
The following images show the website after initialization, after a click on the
insert button and after a click on the
Figure 5: The repeat group after initialization
Figure 6: The repeat group after an insert operation
Figure 7: The repeat group after a delete operation
[XFormsEssentials] Micah Dubinko: XForms Essentials. O'Reilly 2003.
[FormsNG] Hofmann/Liebermann: XForms: The Next Generation of Internet Interfaces. Augsburg 2004.
[Pemberton 2003] Steven Pemberton.
XForms for HTML Authors. [last accessed 24. Mar 2013].
 XForms REST XQuery