How to cite this paper
Cameron, Stephen, and William David Velásquez. “A Data-Driven Approach using XForms for Building a Web Forms Generation Framework.” 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.Velasquez01.
Balisage: The Markup Conference 2013
August 6 - 9, 2013
Balisage Paper: A Data-Driven Approach using XForms for Building a Web Forms Generation Framework
Stephen Cameron
Principal Consultant
Collinta
Steve Cameron worked as a agricultural scientist and then as an information
technologist. His interest in the web and web-technologies for data management and
access arise from this transition.
William David Velásquez
R+D Director
Visión Tecnológica S.A.S.
Programming and XML Technologies Professor
University of Medellín
William Velásquez is co-founder of Visión Tecnológica S.A.S. a Business
Intelligence and Electronic Commerce software company at Medellín, Colombia. He is
actively involved in promoting the use of XML Technologies in SMEs in his country.
Copyright © 2013 A. S. Cameron, W. D. Velásquez Ramirez
Abstract
In a project to build a web-based auto-generated forms framework, we needed to decide
whether to use XForms for the 'designer' user interface as well as for the generated
forms. In trying to make this decision it became apparent that, at a fundamental level,
there are two distinctly different means to develop web-based interfaces. These two
means, or approaches, can be described as 'data-driven' or 'behavioural'. We suggest
that the Model-View-Controller (MVC) design 'pattern', which is now becoming popular
as
terminology for describing the basis of several JavaScript web development frameworks,
is of limited practical usefulness as it encompasses too many variants. In contrast,
the
distinction between 'data-driven' and 'behavioural' approaches seems to be a more
useful. In particular, it provides clarity in distinguishing the respective benefits
of
using 'XML technologies' (particularly XPath) versus other object-based alternatives
for
web application development. This distinction is illustrated using working examples
from
this on-going project. Some implications, such as the role of schema documents in
the
data-driven approach, the practicality of writing XML 'as code', and issues encountered
with the 'XRX' architecture are also discussed.
Table of Contents
- Introduction
-
- XForms: which 'Model-View-Controller'?
- The XForms 'Controller'
- XForms are 'Data-Driven'
- Contrasting Data-Driven and Behavioural Systems
- XForms Applications Use XML For State Persistence
- Implementation
-
- Schemas and Generated Forms
- Designing Complex User Interfaces Using XForms
- Development
- Designer Versions
- Results and Discussion
-
- Are XForms Outdated?
- Are XForms 'Components' Possible?
- The Potential of XForms Attribute Value Templates
- Client-Side versus Server-Side XForms within XRX
- Conclusions
Introduction
The concept of the web as a
giant database
and the use of REST 'resource-based' architectures for
getting data from users or providing it to them in an easy to use way
was well described in a Balisage 2008 paper
Cagle2008
. Specifically, that author describes the attraction of XForms as a means to generate
user
interfaces cost-effectively:
"One final aspect about XForms forms makes them especially attractive as resource
oriented architectures become more prominent. It is possible using schemas and
related modeling tools as sources to generate (via one or more XSLT transforms) a
'preferred' XForms document that can capture much if not all of an underlying XML
data model instance.
This can often be used to create just-in-time editors that cut down dramatically on
the amount of user interface development necessary to build web-based applications,
making such applications far more attractive in situations where the cost of
developing such applications normally significantly outweighs the benefits to
automating these systems, especially when coupled with Atom(Pub) and XQuery based
systems."
Cagle2008
The notion of generating XForms based user interfaces from off a schema is an attractive
one
Spillner
,
Blommestein
. Indeed at one point, an 'XML Forms Generator'(XFG) (generating XForms forms) was
available for free
IBM2006
. In a free and open-source project 'Schema-to-XForms' (S2X)
Cameron2011
to build a web-based generated forms framework, such "editors" (forms) where successfully
generated from an XML Schema
XMLSchema
document as combined HTML and XForms markup.
In order to capitalise on this cost-efficiency, it is also desirable to provide a
similarly cost-effective means to create the schema documents from which the forms
are
generated. Providing such a combined schema designer and forms generator as a single
package, as well as providing a means of saving the generated forms and form submitted
data, would make this web-based approach to data-management an end-to-end solution.
Creation of such a schema designer is a goal of S2X, at the time of writing, one still
at a
'proof-of-concept' stage.
As XForms forms are essentially structured data editors and XML Schema is a XML
structured data format, it was of interest to see if such a schema designer could
be built
using XForms. To the user of this solution it could essentially appear as a 'form
for
designing forms'.
A successful result depends on the capabilities of the W3C XForms recommendation to
handle a complex set of requirements and allow creation of a user interface whose
functionality can be comprehended reasonably easily. In attempting to achieve this
end-to-end solution in S2X it became clear that XForms does provide a very flexible
means
of building complex editors. Also, that an analysis of the conceptual basis of the
XForms
standard and contrasting it with those of other approaches to browser-based user interface
design, would be both useful and informative. Such an analysis would allow a decision
as to
whether the schema designer is fully realisable and also, probably inform the development
of the forms generation process as well.
This paper reports results of that analysis, a description of the work completed to
date, and presents conclusions.
XForms: which 'Model-View-Controller'?
XForms is commonly perceived to be a so-called 'Model-View-Controller' (MVC) kind
of
design; indeed the current XForms 1.1 W3C recommendation
Boyer2009
describes itself as being MVC. Software design 'patterns'
Gamma1994
perform a very important role in making available the accumulated wisdom of others
in
what is essentially a largely creative process, the building of software. But to perform
this role, such patterns must have a clear and specific definition, and example
implementation. As such, Model-View-Controller (MVC) is not a pattern but a category
of
patterns as it has been used to describe a wide range of implementations. A quote
illustrates this problem with MVC:
"Different people reading about MVC in different places take different ideas from
it and describe these as 'MVC'. If this doesn't cause enough confusion you then
get the effect of misunderstandings of MVC that develop through a system of
Chinese whispers."
Fowler2006
As a category, MVC has one constant feature, which is to separate the Model (the data)
from the View (what the user sees) and then to connect, or 'bind', the two such that
changes to the Model are propagated to the View automatically. In the original
description of MVC
MVC
a Controller's function was to mediate between the View and the Model, to receive
input,
either via the View or independently of it, and to update the Model. Another key
function of a Controller was to 'control' the View to enhance the user's mental picture
of the Model.
Subsequently, it is the role and implementation of Controllers in different MVC
implementations that seems most varying, sometimes mediating between the Model and
View
sometimes not.
XForms with its attractive feature of Model-View binding does, we agree, fit within
the
MVC category. However, MVC was defined in the world of object-oriented programming
and
XML as markup is data not an object. There are two important points to make here:
-
The term 'model' in object-oriented programming is used mainly to describe
the features of the language, namely their 'classes' which allow a modeling of
reality in code. Classes encapsulate data (properties) and have behaviour
(methods), modeling of behaviour is primary and properties are usually made
behavioural via getter and setter methods. A key example of this use of the
term model is found in the name of the 'Document Object Model' class, used to
convert markup data into a Document object, made useful via its associated
methods.
-
In the world of the web, the "giant database", the term 'model' is mostly
used in referring to a 'data-model' of data 'resources', or alternately use of
the word 'schema' to refer to a data-model describing the structure and
relationships of the set of conforming 'documents'. Significantly, there is no
behaviour involved in this use of the word 'model'.
This big difference of emphasis in the use of the model concept, between data-modeling
and behaviour-modeling, is one key reason why we suggest that describing XForms as
being
an 'MVC' type of design is not that helpful in attempting to explain the merits of
using
declarative XForms versus other explicitly object-oriented MVC frameworks, particularly
on the web. Instead, we suggest that a more contrasting and technically correct
description of XForms exists, which requires no direct reference to models. Indeed,
the
true MVC pattern which XForms implements causes debate amongst XForms implementors
as
well, as has recently been discussed.
VanDerVlist2013
.
The XForms 'Controller'
Another likely source of confusion around the MVC of XForms is the lack of any explicit
Controller declaration. As stated above, Controllers are a varied and confusing aspect
of MVC generally, but in XForms we are told that there is "an imperative controller
for
orchestrating data manipulations, interactions between the model and view layers,
and
data submissions"
Boyer2009
. Clearly from this definition there is one controller that 'orchestrates' pretty-much
everything behavioural. In fact, people commonly refer to this Controller as being
an
XForms 'engine', a term which reflects this global orchestration function.
In light of this 'implicit' single controller/engine aspect of XForms and, that
XForms is designed to be embedded within a host language, there would seem to be little
reason to differentiate conceptually between the single controller/engine of XForms
and
the agent translating the host language markup into a Document object for the purpose
of
building a View. There is no Controller in the MVC sense of an object created by a
developer to mediate between user, Model and View, which would seem to be a key reason
to want to make use of MVC.
XForms are 'Data-Driven'
This paper proposes that a more informative way to think about the relative strengths
of XForms is by considering it within the context of the broader family of XML
technologies, rather than its links to object-oriented design through its apparent
MVC
implementation.
If XML is data, then we can think broadly of XML technologies as being used to
process data. The way that this processing occurs, in general, differentiates XML
technologies from an object-oriented approach. XML technologies, it can be argued,
simply observe data and 'act' on it, whilst with object-oriented programming, modeling
behaviour is the primary concern and data is generally secondary.
The main strength of the XML approach is efficiency: it provides a universal and very
flexible hierarchical data-modeling grammar, and also has, via the XML standards (XSLT,
XProc, XQuery), means to define our required data processing actions, so allowing
us to
build flexible data processing systems at low cost. Such systems work because the
system
and data are separate and interacting. This approach is usually referred to as
'data-driven programming', for example:
"When doing data-driven programming, one clearly distinguishes code from the data
structures on which it acts, and designs both so that one can make changes to the
logic of the program by editing not the code but the data structure."
Raymond2013
To describe XML technologies as being solely of a data-driven kind is too simplistic,
but if we picture a continuum between the data-separation of pure data-driven and
the
data-encapsulation of pure object-oriented, this provides a useful framework for
analysis of relative strengths of different approaches, like XForms.
We can see that a browser agent is in large part a "data-driven" user interface
"program" that processes HTML and other markup "data" to build a view. So, in the
case
of HTML hosted XForms forms in the browser agent we "make changes to the logic of
the
program" by editing (or generating) both HTML and XForms markup "data". This is the
basis of the declarative approach fundamental to browser function, an approach extended
on by XForms. We can picture this data-driven approach in XForms as providing an
opportunity to efficiently leverage the capabilities of a complex piece of software,
the
browser "program", by sending it declarative ('what' not 'how') instruction "data".
For
programmers familiar with object-oriented languages this is a fundamentally different
paradigm.
Apart from thinking of XForms as being of the data-driven approach, the declarative
"logic" of an XForms form (via actions, refs, binds) is made possible through XPath,
using both its navigational and its predicate definitional power. So, we can go a
step
further and think of XForms as being 'data-structure-driven'.
Contrasting Data-Driven and Behavioural Systems
Our analysis above suggests that the most informative contrast isn't between data-driven
and MVC based user interfaces, but instead between data-driven and behavioural ones.
In
part, this insight came from reading about an object-oriented pattern where an
automatically generated user interface is intrinsic, the so-called 'Naked Objects'
pattern.
Pawson2004
With Naked Objects, any attempt to provide an 'intuitive' user interface using
conventional idioms, such as menus for selection of specific views built to enable
specific use-cases, is abandoned in favour of exposing 'behaviourally complete' objects
directly to the user. Naked Objects systems are said to empower users to solve problems
rather than just to perform prescribed tasks.
The Naked Objects pattern is predicated on taking full advantage of the behaviour
modeling capabilities intrinsic to object-oriented languages. Effort spent building
user
interfaces is considered better spent in building the behavioural system model, as
expressed in choice of classes, class methods and inter-class relationships.
The contrast between a data-driven approach (particularly as expressed in the design
of the World Wide Web) and a behavioural object-oriented approach (particularly that
in
Naked Objects) for building user interfaces is illustrated by the following two
diagrams.
In the Naked Objects pattern, any notion of adding specific customisations to the
generated interface is totally absent. The interface is produced real-time via a
'viewer' layer that interprets the 'class-model' object instances via naming conventions
and class and method annotations. Based on the experience of Naked Objects it's possible
to imagine generation of XForms user interfaces, but only if whatever additional 'logic'
required can be integrated into the source 'data-model' as input to the generation
process, rather than being added to the generated results and so leading to future
maintenance issues.
XForms Applications Use XML For State Persistence
The Representational State Transfer (REST) architectural style is, as the name suggests,
about transfer of state between server and client and vice-versa
Fielding2000
. In the case of our XForms based Schema Designer interface, the state of the designer
is the XML Schema document, and its included annotations, which the user is designing.
This is the 'state' to 'transfer' in a 'representation' format (e.g. XML, JSON) across
the network from the client to a server for persistence, so changing the server state,
then at some later point, to transfer back to the client to restore the designer to
its
original state.
XML is often used in this manner within applications, to "save the work" from the
users perspective but from the application developers perspective, state has a broader
meaning, including hidden aspects of the user-interaction, like an undo-redo history,
user-customised views (often 'Controller' state) etc. This common use of XML for state
persistence is a result of the flexible data-modeling capabilities of XML.
XForms, being effectively a standard for building XML Editors, is at the same time
inherently capable of being used for building applications. This saving and reloading
of
state is simply a matter of submitting (putting) the edited data instance for
persistence to a server and retrieving (getting) it back into the XForms form again
later.
The data-driven nature of XForms forms uses the input markup data to build a
dependency tree that binds data (model) to view. This approach avoids any need for
serialisation and deserialisation of the state of individual controllers in this state
transfer process, as would usually be needed in an object-oriented MVC application.
Implementation
Schemas and Generated Forms
XForms form generation from an XML Schema data-model is suitable for a data-driven
process, as described above, and this is reflected in the choice of XSLT for forms
generation in this project. Using XQuery is another option but the use of XSLT gives
the
option of doing the generation client-side through native support of XSLT 1.0 in most
browsers.
The main features of the forms generation processing are as follows:
-
Schema annotations are used extensively to include transformation guiding
parameter values into schema element appinfo elements.
-
The schema transformation process occurs in two stages, the first stage
produces a logical-model of each form by transforming type references from the
model into equivalent simple or complex element definitions, each form
logical-model so becoming a tree.
-
Also in the first stage, transformation parameters present as schema
'appinfo' annotations are translated into form rendering elements enclosing
their schema element.
-
In the second stage of the transformation, model data instances, and also
binds, are created by traversal of the element trees created in the first
stage. Also, specific templates 'match' the form rendering elements created in
the first stage in order to create the XForms view elements and associated
layout HTML markup.
The main reason for adopting this two stage process, is to provide a more transparent
means for the transformation templates used to create view parts, as described in
item 4
above, to be over-ridden in the second stage through the definition of 'override'
templates with more specific matches. Thus, we hope, providing an effective means
for
specific customisations to be added into the forms generation process.
Designing Complex User Interfaces Using XForms
An equal priority in the S2X project, as the generation of XForms forms from an XML
Schema, has been the creation of an XForms based Schema Designer to allow users to
create their own XML Schema documents. This effort has leveraged both the distinguishing
'data-structure-driven' aspect of XForms and also the use of XML for persistence of
application state, both features of the XForms standard, as described above,
'by-design'.
In terms of the contrast between a data-driven user interface and a behavioural one,
both described above and illustrated in Diagram 1 and Diagram 2 respectively, the
following diagram illustrates the main data-driven features of the Schema Designer.
Although the data-structure-driven approach of XForms is mainly dependent on the
capabilities of XPath, as shown in the above diagram and described in the Introduction,
designing a complex application style user interface requires design aspects that
assist
the user in working effectively. We do desire to guide the user to make appropriate
choices or inputs according to the specific aspect of the data editing task that they
are currently undertaking. To do this effectively we can leverage the Model-View binding
of XForms, and XPath's capabilities, to change the options visible to the user in
a
data-context sensitive way. Note that this is a main contrast to the approach used
in
Naked Objects where options are provided to users through the designed behavioural
completeness of the currently visible 'naked' objects.
The XForms standard provides different means to control what is visible to the user
within this data-context sensitive approach. This capability is taken advantage of
in
both the schema generated forms and the Designer. It's clear that highly dynamic user
interfaces are easily created as a result of this XForms capability, which is actually
an extension of its data-structure-driven basis. To illustrate this point, some specific
aspects of the Designers 'design' data follow:
-
Select parent in repeat and show children via repeat index:
This means is used to allow simplified navigation of a tree (in absence of a
treeview). The children of the xsd:schema root node are displayed using a
repeat (we want to display any schema xsd:element and xsd:type nodes but not
a single initial xsd:annotation node)
<xforms:repeat nodeset="instance('built_schema')/*[not(self::xsd:annotation)]"
id="elements_and_types">
...
</xforms:group>
The currently selected repeat item is displayed as a tree (see next) within
a group
<xforms:group ref="instance('built_schema')/*[index('elements_and_types')+1]">
...
</xforms:group>
-
Making a tree with count of ancestors to get indent spacing:
This means provides a simplified treeview display. We create a simplified
view of the schema, within the group created above we have the following
<xforms:repeat nodeset="descendant::*[self::xsd:element|self::xsd:attribute|self::xsd:sequence|self::xsd:all|self::xsd:choice|self::xsd:group]"
id="element_details">
<div>
<xforms:output value="substring('                  '
,1,3*(count(current()/ancestor::*[not(self::xsd:element|self::xsd:complexType|self::xsd:simpleType)])))" />
<xforms:trigger class="node_label" appearance="minimal">
<xforms:label>
<xforms:output value="concat(local-name(),': ')" />
<span class="element_name"><xforms:output value="@name" /></span>
</xforms:label>
...
</xforms:trigger>
</div>
</xforms:repeat>
-
XForms group as a means of making relevant alternatives visible and invisible:
This means is used much like a switch/case statement in an imperative
language to display only one option amongst several at a time in a
data-driven way. This is an important part of the Editor functionality as
the choices already made by the user guide what new options become visible
as the Schema is created. The xform group The XForms switch/case has a
different functionality (see next).
<xforms:group ref="self::xsd:element[not(@type/text()) and not(xsd:simpleType or xsd:complexType)]">
...
</xforms:group>
<xforms:group ref="self::xsd:element[@type/text() or xsd:simpleType/xsd:restriction]">
...
</xforms:group>
<xforms:group ref="self::xsd:complexType[count(child::*)=1]">
...
</xforms:group>
<xforms:group ref="self::xsd:group[not(xsd:all|xsd:choice|xsd:sequence)]">
...
</xforms:group>
...
-
Changing help messages to be relevant to a selected item in a select1 control:
<xforms:select1 ref="@as">
<xforms:label>
<xsl:value-of select="Render as:" />
</xforms:label>
<xforms:hint>
<xsl:value-of select="Select an option from the list to control the form rendering outcome." />
</xforms:hint>
<xforms:help>
<xforms:output ref="instance('rendering')/s2x:render-option-list[s2x:render-for='xs:schema/xs:element']/s2x:render-option[@as=current()]/s2x:description" />
</xforms:help>
<xforms:itemset nodeset="instance('rendering')/s2x:render-option-list[s2x:render-for='xs:schema/xs:element']/s2x:render-option">
<xforms:label ref="s2x:title" />
<xforms:value ref="@as" />
</xforms:itemset>
</xforms:select1>
Development
In order to handle the size and complexity of the Designer XForms form (3.000+ lines
of XML data), it has been split into several view subsections that can be independantly
developed and tested. These subsections are built independantly and also are 'compiled'
into the Designer using XSLT 2.0 stylesheet transformations. The latter is achieved
using the xsl:import feature of the data-driven XSLT, allowing the subsection templates
to be imported and used within the super designer.xsl template. XSLT also allows
internationalisation of the forms to be done here as well.
Designer Versions
Currently we have two Designer versions a simple and complex one. The former was
created more recently to test the idea of generating the XForms form on the browser
client using XSLT 1.0 stylesheet. It uses uses a smaller subset of XML Schema (only
simple types and complex sequence types) and generates just one XForms form. The current
emphasis is on this simple Designer with the goal of soon having a finished version
that
produces useful web-forms.
The more complex version is under review, it was started as a proof-of-concept and
now needs to be evaluated before more work can be devoted to it, given limited
resources. This version uses a server-side XSLT 2.0 stylesheet for XForms form
generation, allowing multiple forms to be created off a single schema.
Results and Discussion
In this project to date we have demonstrated the capabilities of XForms for building
a
complex XML Editing application, namely an XML Schema designer. Also, that the data-driven
nature of XForms integrates well with other data-driven XML technologies, specifically
XSLT, in a browser to allow the generation of complex but functional XForms forms
using a
schema from the designer as input to the XSLT transformation. In the case of the simple
designer, all the above is done within the browser. In this result we feel we have,
at
least in large part, demonstrated the cost-efficiences of this approach forecast previously
Cagle2008
.
A key question for us now is how to make this data-driven approach work best within
the
larger client-server framework. That is to find an optimal balance of client-side
and
server-side functionality to find further efficiencies. Others have been down this
path
before us, however our interest in producing something of wide general usefulness
has
perhaps allowed us to work on specific areas where others have not delved. We aren't
claiming that our approach is optimal, that is still unclear, but we feel that as
a
proof-of-concept it has highlighted the potential of data-driven XForms and also helped
in
the refinement of the
XSLTForms
browser XForms support emulation framework.
Given the positive results obtained to date we feel its worthwhile discussing a few
general issues about the future of the XForms standard.
Are XForms Outdated?
In the introduction above we have contrasted data-driven systems with a behavioural
systems and made the claim that XForms and XML technologies are generally of the
data-driven type while MVC implementations are generally behavioural. Browser based
web-applications are mostly given dynamic behaviour using JavaScript but this behaviour
is never refered to as being 'MVC'. The clean separation of data and view in the browser
seems more a 'data-driven' key characteristic than it is an MVC one. That we can also
dynamically change whole sections of the view by replacing parts of the data tree,
through setting the innerHTML property of a DOM Node confirms this somewhat.
However, we aren't claiming that is is an mutually exclusive contrast, these are two
extremes of a continuum. What we are hoping to do to is increase the awareness of
the
advantageous characteristics of the data-driven approach, for building particular
kinds
of systems efficiently.
In our definition of data-driven we specify that the agent responds to data rather
than
the other way around, so on this basis the popular jQuery isn't data-driven but it
does
seem to be a move away from the behavioural object-oriented DOM back towards a
declarative data-driven style. It's informative to mention here the 'Data-Driven
Documents' (D3) JavaScript library developed to create data visualisations in browsers:
"With D3, designers selectively bind input data to arbitrary document elements, applying
dynamic transforms to both generate and modify content"
Bostock2011
So on this basis, there are two possible contrasting conclusions that can be made:
-
The selector approach of jQuery or D3 represents a good compromise between
the data-driven and behavioural approaches and will be built upon or copied by
other JavaScript libraries, resulting in XForms, in practice, becoming
completely redundant!
-
That exposing the DOM to manipulation with JavaScript has been a compromise of
the basic 'data-driven system' design concept of browsers all along, and that
an alternative more suitable language is now available and should be supported
natively by browsers, namely XQuery
XQIB2012
.
That these two possible conclusions are so contrasting is obvious and this paper
doesn't attempt a resolution. However, there is an obvious academic interest in
exploring the second conclusion, which this paper does in a limited way do, by exploring
XForms. Adding XQuery native support to a browser and seeing what can be done with
it,
is a better alternative. Using FLOWR statements to transform a browser DOM Document
is a
very interesting idea!
Are XForms 'Components' Possible?
Forms are a user interface to data, but as a data-driven 'technology', XForms have
a
data-first, design-second fundamental basis. This is due to the fact that the 'current
(data) context' is such key feature of the way that they work and understanding this
feature is a necessity for XForms form designers.
If we adopt the 'XForms are MVC' viewpoint there does seem to be a potential trap
of
thinking that reusable components would be good feature to add to XForms. In this
project, in the building the very large complex Designer XForm, we encountered a major
problem of managing the amount of markup and something like the idea of XForms
components is attractive. Instead we came up with the idea of using XSLT to compile
a
larger form from subsections, this made some sense as we also use this transformation
to
include language specific strings into the form. We could use the data-driven features
of XForms to allow the user to swap languages on-the-fly, this is done in the simple
version but was considered a burden that might slow performance in the complex version,
though not tested.
With the data-driven nature of XForms the idea of components is not an easy match,
however in terms of managing the construction of a large form or a large suite of
forms
the notion of subforms, with the benefit of our analysis, does make good sense. We
see
these as being editors of a specific section of the data-model that can be used both
independantly or within a parent form. Subforms as implemented in
XSLTForms
seem to work in the manner that a subform gets absorbed into the parent form, so keeping
within the single controller/engine/agent data-driven paradigm that we have described.
In our large form we have no slow form loading-time problem now and we don't see great
benefit in the idea of dynamically loading (or unloading) subforms into the parent
form
in order to speed-up intial parent form loading-time.
To conclude this section on whether reusable components are useful in XForms, over
and above the subforms concept that does fit within the data-driven basis of XForms,
one
similar suggestion is that the XForms 'group' element could be extended by adding
an
optional 'src' attribute, such that the contents of the parent group are replaced
by the
contents of an identified group in the linked source document at load time.
XSLTForms
has recently added an experimental 'component' tag, we suggest that this name sends
the
wrong message about the nature of XForms to new users, whereas extending the use of
XForms group does not. Our idea is not to make such imported groups like subforms
with
their own models, but simply to provide a means of managing a large body of XForms
markup in separate files. Essentially this is the same as how data instances are done,
as either embedded or as linked resources. It is likely that having this new feature
would solve the data management issues we encountered in this project.
The Potential of XForms Attribute Value Templates
If we think of XForms in a broad context of data-processing, we frequently desire
to
build data viewing interfaces as much as data collection interfaces, or, a combination
of both. XForms Attribute Value Templates (AVTs) offer a means to do this, particularly
they allow the integration of HTML or Scalable Vector Graphics (SVG) elements (via
their
attributes) into the XForms Model-View binding. Having discounted the concept of XForms
components, in the sense of a diverse range of reusable view 'objects' (or 'widgets'),
AVTs do offer a mechanism to extend the data-driving of XForms into its 'host' languages
of HTML and/or SVG.
The idea of extending the use of the XForms group element to allow it to be used to
pull a block of markup into a form at client-side at load-time, in combination with
use
of AVTs in that block, does seem to offer a powerful means to 'modularise' (as opposed
to 'componentise') XForms creation and at the same time keep within the RESTful approach
of caching resources client-side whenever possible.
We can imagine an XForms form similar to our current Designer with a graphical
capability similar to that seen with D3 being achievable with such extended groups
and
AVTs, evaluation of this possibility is the key thing to do in deciding the future
progress of our current complex Designer.
Client-Side versus Server-Side XForms within XRX
One of the initial motivations for starting this work was to show that a client-side
XForms engine was superior to a server one. Our analysis of XForms as being data-driven
and as such, an extension of fundamental browser functionality, as well as the result
of
our complex Designer being a mostly successful proof-of-concept, confirms this stand.
We
say that if XForms was actually supported natively by browsers any debate about
server-side and client-side XForms would mostly disappear.
So, XForms designers are unfortunately caught in a compromise world of having to work
with things as they are but dreaming of things as they should-be. This seems to us
to be
particularly so with the so-called XRX architecture and specifically the REST part
of
it. Server-side XForms implementations are taking advantage of one aspect of REST,
namely the uniform constrained interface of the HTTP verbs, but ignoring the primary
"why" concern of Representational State Transfer which is to improve performance of
remote networked clients by caching resources as close to the client, or on it, as
possible.
To justify a server-side XForms emulation solution with concerns about exposing
sensitive business logic to the user and at the same time advocating XRX, does indicate
a likely case of "a solution in search of a problem". We suggest that such concerns
about business logic are likely to indicate that a non-XRX system is possibly going
to
be a better one to use (and the Naked Objects frameworks one good option to consider).
Our analysis and results indicate that the "sweet-spot" of XRX is data-focused
systems where the data-driven nature of XML technologies and particularly XForms is
of
most benefit. Such XRX data-focused systems are characterised by transferring their
parts as RESTful data resources, that is, the data instances and data-model schemas
linked to the XForms forms and also thinking of the forms themselves as data (and
subforms and potentially groups as well).
If any compromise of this 'full XRX' approach is to be considered it does makes some
sense to put an XForms model on the server and replicate it to one or more collaborating
clients, but also to keep the client(s) in charge of model-view binding via their
dependancy tree, the source of the data-driven basis of XForms.
The high cost-effectiveness of XRX specifically for 'data-driven' application
development is of great significance, but a perspective, or insight, which we suggest
has not been specifically communicated, or demonstrated, to-date. Perhaps, one good
place to start in this is to ban the editing of XML text and to build a generic
'graphical' XML Editor based on XForms
Cameron2012
. We intend to create such a full data-driven application demonstration in the near
future.
Conclusions
-
One of the design goals of XML was "XML documents should be human-legible and
reasonably clear"
XML1.0
Note that the goal was to make it "human-legible" not "human-writeable". Surely in
the mind of its creators they were thinking of an ideal world, where XML would be
widely adopted and lots of applications would be created to assist people in the
creation of XML documents while hiding the markup.
Maybe the perceived "low acceptance" of XForms is due to the lack of that kind of
applications and the only means available to create XForms forms are simple text
editors or XML validating editors in the best case.
-
The power of the idea behind XForms
Although there is a perception of failure in the XForms initiative, the best probe
of power of its foundations and well planned architecture, is that XForms can be used
even to create XForms forms, as has been done in this project.
It was just matter of time to have competent XForms runtimes, as the ones
available now, in order for this first XForms based XForms Designer to be possible
and further we'll start to see XForms used in more applications.
-
The ability to generate Graphical User Interfaces directly from data-models, opens
new fields of application:
-
Create XML based applications writing much less code
-
Reduce the time needed to create an XForms User Interface
-
Allow non-programmers to create XML based applications
-
Ease the creation of applications based in existing XML data
-
The way forwards.
The idea of applications based on XForms and other XML Technologies have not had a
high success rate when compared to object-oriented systems. In fact, they now seem
mainly restricted to high-cost systems and specialised publishing roles. Yet their
potential to provide very cost-effective solutions, as explored in the work done and
reported in our paper, seems largely unrecognised outside of a relatively small
community of XML and XForms enthusiasts.
From our proof-of-concept work and an now our identification of 'Data-Driven' as
being the defining nature of these applications, we think that developing working
real-world example systems of high quality and making them available at low cost,
or
free, is the only way forwards. The main framework elements of this approach are
freely available and so the main task now seems to be to push the envelope as to what
is possible. Hand-editing XML is something that we don't see as being a big part of
that effort, nor should system users. Also, deploying scarce human resources to build
such example systems requires cooperation from interested parties for any effect
(Having sponsorship is good as well).
-
Acknowledgments.
Our thanks go to the 'data-structure-driven' XForms standard, its designers and also
its implementors, particularly to Alain Couthures, for his work on the client-side
XForms implementation
XSLTForms
. We see keeping XForms in the client "where it rightfully belongs" as being the best
way forwards.
References
[Blommestein]
Fred van Blommestein. "eb-forms".
http://www.eb-forms.com
[Bostock2011]
Michael Bostock, Vadim Ogievetsky and Jeffrey Heer. “D3: Data-Driven Documents”. 2011.
http://vis.stanford.edu/files/2011-D3-InfoVis.pdf
[Boyer2009]
John M. Boyer, Editor. "XForms 1.1: W3C Recommendation 20 October 2009"
http://www.w3.org/TR/2009/REC-xforms-20091020
[Cagle2008] Cagle, Kurt. “REST Oriented
Architectures (ROA): Taking a resourceful approach to web data.” Presented at Balisage:
The
Markup Conference 2008, Montréal, Canada, August 12 - 15, 2008. In Proceedings of
Balisage:
The Markup Conference 2008. Balisage Series on Markup Technologies, vol. 1 (2008).
doi:https://doi.org/10.4242/BalisageVol1.Cagle01.
[XSLTForms]
Alain Couthures. "XSLTForms"
http://sourceforge.net/projects/xsltforms
[Cameron2011]
Stephen Cameron, William Velásquez. “Schema-to-XForms”. 2011.
http://sourceforge.net/projects/schema2xforms
[Cameron2012]
Stephen Cameron. “xml.edit.xml”. 2012.
http://sourceforge.net/projects/xmleditxml
[Fowler2006]
Martin Fowler. "GUI Architectures".
http://martinfowler.com/eaaDev/uiArchs.html
[IBM2006] Kevin E. Kelly, Jan Joseph Ktraky, Keith
Wells, and Steve Speicher. "XML Forms Generator". March 2006. IBM alphaWorks.
[MVC]
Trygve M. H. Reenskaug. "MVC: XEROX PARC 1978-79".
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
[Pawson2004]
Pawson, R., Naked Objects, Ph.D Thesis, 2004, Trinity College, Dublin, Ireland, Page
3
http://downloads.nakedobjects.net/resources/Pawson%20thesis.pdf
[Fielding2000]
Fielding, Roy Thomas (2000), Architectural Styles and the Design of Network-based
Software
Architectures, Doctoral dissertation, University of California, Irvine. Chapter 5.
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
[XML1.0]
Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau. "Extensible
Markup Language (XML) 1.0 (Fifth Edition)". W3C Recommendation 26 November 2008.
http://www.w3.org/TR/2008/REC-xml-20081126/
[Gamma1994] Erich Gamma, Richard Helm, Ralph Johnson,
John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software".
Addison-Wesley. 1994. ISBN 0-201-63361-2
[Raymond2013] Eric Steven Raymond. "The Art of Unix
Programming". Addison-Wesley, September 17, 2003, ISBN 0-13-142901-9
[Spillner] Joseph Spillner, Alexander Schill.
"Analysis on Inference Mechanisms for Schema-driven Forms Generation"
[VanDerVlist2013] Eric van der vList. "When MVC
becomes a burden for XForms". Presented at XML London 2013
[XMLSchema]
David C. Fallside, Priscilla Walmsley. "XML Schema Part 0: Primer Second Edition".
W3C
Recommendation 28 October 2004.
http://www.w3.org/TR/xmlschema-0/
[XQIB2012]
ETH Systems Group, FLWOR Foundation, 28msec Incorporated. "XQuery In The Browser (XQIB)
JavaScript Library". 2012.
http://www.xqib.org
×Cagle, Kurt. “REST Oriented
Architectures (ROA): Taking a resourceful approach to web data.” Presented at Balisage:
The
Markup Conference 2008, Montréal, Canada, August 12 - 15, 2008. In Proceedings of
Balisage:
The Markup Conference 2008. Balisage Series on Markup Technologies, vol. 1 (2008).
doi:https://doi.org/10.4242/BalisageVol1.Cagle01.
×Kevin E. Kelly, Jan Joseph Ktraky, Keith
Wells, and Steve Speicher. "XML Forms Generator". March 2006. IBM alphaWorks.
×Erich Gamma, Richard Helm, Ralph Johnson,
John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software".
Addison-Wesley. 1994. ISBN 0-201-63361-2
×Eric Steven Raymond. "The Art of Unix
Programming". Addison-Wesley, September 17, 2003, ISBN 0-13-142901-9
×Joseph Spillner, Alexander Schill.
"Analysis on Inference Mechanisms for Schema-driven Forms Generation"
×Eric van der vList. "When MVC
becomes a burden for XForms". Presented at XML London 2013
×
ETH Systems Group, FLWOR Foundation, 28msec Incorporated. "XQuery In The Browser (XQIB)
JavaScript Library". 2012.
http://www.xqib.org
