XForms Archives

February 7, 2007

XForms, XForms Tiny and Web Forms 2

There have been a lot of debate about XForms and the whatwg Web Forms 2 initiative. At the moment the subject is hotter than ever since the XForms working group has to be rechartered. In this new charter is a proposal from XForms to create a XForms Tiny version which will assimilate the Web Forms 2 syntax but be convertible to XForms by e.g. a XSLT transformation. Dave Raggett has been a key driver for this and have created a prototype of such a language which is based upon a JavaScript library. This is in short words the history behind a longer discussion on the www-forms mailing list where a comparison has been made between XForms Tiny (as proposed and implemented by Dave Raggett) and Web Forms 2.

I have been a member of the XForms working group through many years now and have to air my concerns for the proposed route in the new XForms charter. Therefore I send a member only mail to the working group which I now choose to publish on my blog:

It seems from the public discussion that we are starting to have a notion of XForms Tiny and XForms Full. For an implementor which have an XForms 1.0 processor this is a problem as the language between tiny and full are very different and will actual require two code bases. This is a problem for implementations which has strict requirements to code size which is the case for mobile solutions. Furthermore a mobile solution is very unlikely to support JavaScript and will not be able to use an open source library since that would require support for not only a JavaScript engine but also the exposure of standard interface, e.g. to the DOM (again this will increase the code base). It is unlikely that customers will understand that XForms Tiny is something completely different from XForms "Full" and that it would not be possible to "just get the tiny profile". In other specification from w3c the difference between full and tiny is usually defined as a logical subset of features (e.g. SVG and CSS).

I have repeatedly asked for a reason we do this XForms Tiny work and have not received a clear answer other than "we do this before somebody else do it for us". But frankly there are lot of open source frameworks out there and even though XFT is really cool and uses many of the same design criteria as XForms did, it seems it has little to do with the work we previously have done in XForms and hence the naming is very misleading.

It is clear the XForms will not be mainstream as HTML Forms and it will never find its way to the "please contact me" form. It is also clear that it is that kind of functionality WF2 tries to enhance which make perfect sense in an evolutionary way. In XForms we provide some pretty complex semantic constructs which enables authors to describe relationships between data and between data and UI. This is what we call the processing model and it is what makes XForms worth while. This processing model makes it possible to declaratively describe entire applications with a rich UI only based upon data. This is the real difference between XForms and Tine/WF2 (e.g. the processing model vs. event based updates) not some syntactic sugar as element names or if the label is inside or outside the form control element and what a repeating structure means. This is also why XForms should not standardize on XForms Tiny as it is put out today but consider a normal w3c profiling of the "full" version.

In the working group we put a lot of effort in discussion political positing of XForms. It seem the original goal has been to replace HTML Forms (which is quite clear as the specification originates from xhtml). Because of the complex design requirements put out for XForms the goal will not be meet simply because XForms *did* fulfill these requirements but as a side effect made the language to complicated for simple use. Attempts to argument that XForms is not complicated by creating examples like a simply search has been put out there on the web. But when it comes down to grasp XForms in entirety we must face the fact that it is complicated but at the same time extremely powerful.
So when we discuss chameleon namespaces because we want to reach out for the simple usecases we are wasting our time. People using XForms understand constructs as namespaces as they will come with an XML background e.g. from XSLT, XPath, XMLSchema, SVG or ... If they do not come with this background it is unlikely that they would choose XForms over something like an open source JavaScript widget library. We should therefore focus on creating the many improvements we really need in XForms to make the users of XForms happier and not try to please a crowd which does not like the smell of XML.


February 28, 2007

PicoForms Releases New Site

Screenshot of the PicoForms WebSitePicoForms, the company I work for, has released a new website which contains a complete make over of the design but more importantly demos of the products we have. There is a great demo of the MIDP implementation (at PicoForms we call this the Micro Edition Browser) which uses several back-end WebServices to retrieve data directly from the forms using SOAP. There is also a WebStart demo of the Personal Edition Browser, which currently only have one demo form but a good one since it is the Tax Form from the Mozilla XForms Project.

Check it all out on

March 22, 2007

Picax Web Album

Picax Web AlbumI have created a AJAX library and released it under GPL to be used for publishing Picasa albums on webpages in a simple way. The XML files generated by Picasa is used directly and is attached to the gallery's album tab by adding an entry in another XML file.

I wrote this Picax gallery software for two reasons:

  1. I needed a gallery for my site
  2. I wanted to make a real AJAX application to compare it with XForms/a declarative approach.

Now creating Picax was no problem but even under development I got confused about the element layout because it was created in the script. I kept making the structure in html and then converted that to script. Using a declarative approach I would have been able to directly express the structures and would have made it much simple to extend and maintain the application. For my next project I will redo the Picax in XForms+XHTML and make a real comparison between the two methods.

For now feel free to use the gallery on your site, if you like me, are a user of Picasa and want to publish your pictures on the web.

June 2, 2007

XForms and sorting

One problem that keeps popping up when creating forms with XForms is the lack of sorting. I wrote a simple sorting extension which was mostly just taken from XSLT and published it on However this is only useful then the XForms implementation has support for the extension and often is will not. But many times there are alternatives and in this blog post I will describe how one can possible do sorting in the Firefox XForms extension.

There is two places where one might want to sort; either in the UI or in the instance it-self. Because of the way XPath works it is difficult to only sort in the UI as it changes the behavior of XPath and might mess up the rest of the context update routine in XForms. Here I will demonstrate how to solve sorting by sorting an instance.

In this example we will have a model which contains two instances:

  1. data document which we want to sort

  2. the stylesheet document

We keep the stylesheet that do the sorting in an instance because it will allow us to change its behavior from XForms by altering attributes and content.

Without futher ado I give you the model:

<xf:instance id="default-instance">
<data xmlns="">

<xf:instance id="stylesheet">
<xsl:template match="/">
<xsl:apply-templates select="data/item">
<xsl:sort type="string" select="name"/>

<xsl:template match="*|@*|text()">
<xsl:apply-templates select="*|text()|@*"/>

Here the instance we want to sort is the first and we have the XSLT stylesheet for doing the actual sort as the second instance. Now all we need is a script which will take the XSLT stylesheet and the instance, sort and then insert the sorted instance back into the model. Then the model must be updated and that is it. The script for doing this goes as follows:

function sort_instance(id) {
// We get the instance element
var instanceElement = document.getElementById(id);
if (instanceElement!=null) {
// XForms exposes the retrival of the instance document from the model element which *should*
// be the parent for the instance element.
var instance = instanceElement.parentNode.getInstanceDocument(id);
if (instance!=null) {
// Now creating the stylesheet, for this example the stylesheet document is also an instance
// by it can be loaded from many difference sources
var xslDom = instanceElement.parentNode.getInstanceDocument('stylesheet');

// create an XSLTProcessor and attach the stylesheet
var processor = new XSLTProcessor()

// now we do the sorting transformation
var resultDom = processor.transformToDocument(instance, instance);

// we then move the result info the instance dom

// and performs the updates for XForms

This script can then be called from e.g. an anchor like <a href="javascript:sort_instance('default-instance')">sort</a>. The full example can be downloaded or tried from here.

About XForms

This page contains an archive of all entries posted to David Landwehr's blog in the XForms category. They are listed from oldest to newest.

Offspring is the previous category.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33