How to cite this paper
Processing XForms in HTML5-Enabled Browsers
Balisage: The Markup Conference 2013
August 6 - 9, 2013
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
How has forms technology for the Web evolved over time? There are two lines of
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.
XForms needs to be embedded into a host language, which most commonly is HTML.
Nevertheless, in contrast to HTML forms, which are part of the W3C HTML Recommendation,
Web browsers are not obliged to support XForms natively. Attempts to make XForms a true
part of HTML in XHTML 2 have been abandoned by the W3C together with XHTML 2
in favor of HTML5. In fact, none of the current mainstream browsers support XForms
natively. Browser plug-ins come closest to native XForms support. There used to be a
Firefox plug-in Mozilla XForms that has no developer's support any more and is no longer
compatible with current versions of Firefox. FormsPlayer, a plug-in XForms processor for
Internet Explorer, is also no longer supported. Current XForms implementations
(XSLTForms, BetterForms, Orbeon Forms) translate an XForms form into an HTML form and
architectures for both the translator and the form execution code.
Tobias Niedl, the first author of this paper, has explored under supervision of the
APIs that an HTML5-enabled Web browser provides as an implementation platform for an
XForms processor. It turns out that the new facilities of HTML5-enabled browsers can be
used to support XForms more natively. In a similar way as the plug-in solutions the code
which executes the form is programmed directly, not generated. This removes a level of
indirection in the interest of clarity and maintenance. But in contrast to plug-in
an HTML5-conformant browser supplies. For its reach, it capitalizes on the market power
of the major browser vendors in the WHATWG, who stand behind HTML5.
Tobias Niedl has designed and implemented an XForms processor on the platform of an
structures when an HTML page with an embedded XForms form is loaded and acts as an
XForms processor during the lifetime of the document in the browser, making use of APIs
that an HTML5-enabled Web browser must support.
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
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
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
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
imply requirements for any XForms processor. We discuss these
implications in detail below, contrasting them with the lesser requirements of HTML
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
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
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,
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.
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.
Today's Web browsers can parse XML files and translate them into data structures
of a higher level of abstraction. Web browsers make these data structures available
to programming languages via the standardized Document Object Model (DOM) interface.
data in the browser via DOM. HTML5-enabled browsers support an advanced version of
DOM that is specified by WHATWG and also addresses parsing and serialization of XML
documents to and from DOM. The XMLHttpRequest specification enables modern Web browsers to transfer DOM objects or XML-encoded
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
createNSResolver() generates a namespace resolver
object for all namespace definitions that are in scope at a specific DOM
XML Events and XML Schema
Current Web browsers support neither XML Events nor XML Schema.
Documents and XML submission
In a Web browser new DOM document objects can be created on the fly using
browsers meet the requirements of XForms here.
A data model (or rather the document representing it) can be submitted as a XML
string according to the XForms specification. Most Web browsers implement the XMLHttpRequest interface which provides (a)synchronous communication to a Web server
or another type according to XMLHttpRequest specification. As each data model is
handled as an independent DOM Document, and the XMLHttpRequest specification enables
a browser to transfer such a Document without conversion, the combination of
Document and XMLHttpRequest fits well for the mentioned XForms requirements.
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.
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
processor called xf.js. The goal of the implementation was not to provide full support
for XForms but to evaluate the capabilities of Web browsers with HTML5 as platform for a
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
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
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
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:
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
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
First, Web browsers do not permit access to the local file system to
existing one cannot be implemented without using additional technologies, like
Adobe Flash or another browser plug-in which is able to access the local file
system. HTML5 defines the Web storage interface which allows the storage of data on the local system in a
key-value pair manner. But Web storage meets the requirements of XForms only
partially as XForms allows the specification of a URL pointing into the local
file system for storing the data model. Browsers providing the Web storage
interface act as a simple database, but do not allow the user to choose the
destination of the stored information.
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
XForms the content of a file, which was selected using the upload widget, can be
embedded into the data model as binary content. The HTML5 counterpart widget has
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
An important functionality is the support of XML Schema which is not given at the
for the xf.js processor.
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:
</xf:input> <br />
Will result in the following XHTML5 code:
<input type="text" name="FNinput_Input" value="Back to the Future" form="FN_model1" />
<output name="output" form="FN_model1">Back to the Future</output>
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:
<name>Dr. Emmet Brown</name>
<xf:setvalue ev:event="DOMActivate" ref="instance('inst2')/name" model="model2">DeLorean DMC-12</xf:setvalue>
<xf:output ref="instance('inst2')/name" model="model2">
<xf:label>Time machine: </xf:label>
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
<xf:repeat id="carRepeat" nodeset="car">
<xf:label>Insert new car at beginning</xf:label>
<xf:insert nodeset="car" at="1" position="before"/>
<xf:label>Delete last car</xf:label>
<xf:delete ev:event="DOMActivate" nodeset="car" at="last()"/>
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