Niedl, Tobias, and Anne Brüggemann-Klein. “Processing XForms in HTML5-Enabled Browsers.” Presented at Balisage: The Markup Conference 2013, Montréal, Canada, August 6 - 9, 2013. In Proceedings of Balisage: The Markup Conference 2013. Balisage Series on Markup Technologies, vol. 10 (2013). https://doi.org/10.4242/BalisageVol10.Niedl01.
Balisage: The Markup Conference 2013 August 6 - 9, 2013
Balisage Paper: Processing XForms in HTML5-Enabled Browsers
Has studied computer science at the TU München and works today as Software
Engineer in Munich. XML was one of his major field of study during his Master
course. The introduced XForms processor was developed as part of his Master
Thesis.
Forms technology for the World Wide Web has developed along two lines. The XForms
strain has worked for a cleaner separation of concerns and supports more complex
bindings between user interface and data. The HTML strain has focused on the user
interface, defining new widgets and in HTML5 adding type definitions to form
elements to enable native in-form validation. Some XForms implementations translate
XForms elements into HTML widgets plus executable code. But HTML5 also defines new
Javascript APIs browsers should support. The new facilities of HTML5-enabled
browsers can be used to support XForms near-natively. We explain how.
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.
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
JavaScript code. There are purely client-side, purely server-side and distributed
architectures for both the translator and the form execution code.
Tobias Niedl, the first author of this paper, has explored under supervision of the
second author, as part of his Master Thesis at TU München, JavaScript and the new
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
solutions, it is platform independent, relying only on the APIs and the JavaScript
that
an HTML5-conformant browser supplies. For its reach, it capitalizes on the market
power
of the major browser vendors in the WHATWG[1], who stand behind HTML5.
Tobias Niedl has designed and implemented an XForms processor on the platform of an
HTML5-enabled Web browser. A JavaScript program called xf.js sets up some data
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
forms.
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.
Data model
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[2] 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.
Events
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[3]. 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[4].
A form reacts to an event by executing an action. In HTML forms, actions are
custom-programmed pieces of script, often JavaScript; actions are associated with
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 message, setvalue or
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.
Widgets
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].
Repetitions
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[5], 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 repeat element.
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 repeat element.
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.
XML
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.
Furthermore, new DOM objects can be created in a Web browser under JavaScript
control. JavaScript programs that run in the browser can read, modify and extend XML
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[6]. The XMLHttpRequest specification[7] enables modern Web browsers to transfer DOM objects or XML-encoded
strings.
XPath
With Document Object Model (DOM) Level 3 XPath Specification[8], W3C defines an interface to query a DOM object with an XPath 1.0
expression. The interface provides, among others, the following two methods:
The method evaluate() evaluates an XPath expression against a
DOM node.
The method createNSResolver() generates a namespace resolver
object for all namespace definitions that are in scope at a specific DOM
node.
Modern Web browsers support this specification and its JavaScript binding.
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
JavaScript. As XForms requires to handle each data model as an independent document,
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[9] interface which provides (a)synchronous communication to a Web server
out of a JavaScript program. The data to be sent can be a String, a Document object
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
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.
Table I
XForms
HTML5
Details
input
input
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.
output
output
-
label
label
-
trigger
input, button
In HTML5: The type attribute on the input element has to be
set to button.
submit
input
In HTML5: The type attribute has to be set to submit.
secret
input
In HTML5: The type attribute has to be set to password.
textarea
textarea
-
upload
input
In HTML5: The type attribute has to be set to file. But see restrictions in xf.js below.
range
input
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
as follows:
start (HTML5) to
min (XForms)
end (HTML5) to max (XForms)
step (HTML5) to step (XForms)
select1 (full)
input
In HTML5: The type attribute has to be set to radio. In XForms there is one select1
containing a list of options. In HTML5 there must be one
input element per option.
select1 (compact)
option
In HTML5: The size attribute has to be set to a value greater than "1".
A browser will display it as a listbox.
select1 (minimal)
option
In HTML5: The size attribute has to be set to "1". A browser will
display it as a drop down selection box.
select (full)
input
In HTML5: The type attribute has to be set to checkbox. In XForms there is one select
containing a list of options. In HTML5 there must be one
input element per option.
select (compact)
option
In HTML5: The size attribute has to be set to a value greater than "1".
Additional the multiple attribute has to be set.
select (minimal)
option
In HTML5: The size attribute has to be set "1". Additional the multiple
attribute has to be set.
Repetitions
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
This section describes the implementation of the prototypical pure JavaScript XForms
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
XForms processor.
Principles
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.
Architecture
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.
xfModel class
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
the model element are related in a direct way (e.g.
instance or 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 instance
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
interface.
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
form element.
xfInstance class
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[10]. 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[11] to generate a XML string. For submission as name-value pairs the
getDataAsHashMap() method flattens the model data down as specified by XForms
before submission.
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 submit
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.
xfBind
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[12] interface which was introduced in HTML5 on the form
element.
Widgets
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[13] 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
model.
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
element itself.
The 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 repeat
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 insert,
setvalue, delete and message and the
superior element 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.
Evaluation
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).
Missing technology
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
use a JavaScript based XML Schema implementation, as provided by
xml.js[14].
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[15]. 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.
As the xf.js processor is implemented in JavaScript all restrictions of the
JavaScript interpreter in a Web browser also apply for the xf.js processor
itself.
First, Web browsers do not permit access to the local file system to
JavaScript programs. Thus saving a data model on the computer or opening an
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[16] 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
reasons.
The JavaScript restrictions also prevent a working upload widget element. In
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
no interface to fetch the file content via JavaScript. As the access to local
files is not possible in general, a pure JavaScript based XForms processor lacks
this feature.
Summary
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:
model, instance, bind and
submission. For the user interface, the elements label,
input, output, trigger, submit
and repeat are supported. To show the capabilities of Web browsers towards
events, the xf.js processor implements the Action elements insert,
setvalue, delete, 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.
Outlook
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
nodes with a set of JavaScript functions which provide the needed functionality for
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
called.
An important functionality is the support of XML Schema which is not given at the
moment. It has to be checked if JavaScript implementations for XML Schema can be used
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.
Widget replacement
The first example shows how the document is modified when the XForms widget
elements are replaced by HTML5 widgets.
<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:
