The concept of the web as a
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
. Specifically, that author describes the attraction of XForms as a means to generate
"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.
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>
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.
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?
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.
So on this basis, there are two possible contrasting conclusions that can be made:
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.
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).
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.
[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.
[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