XForms and Declarative Applications
Steven Pemberton, W3C/CWI, Amsterdam, The
Netherlands
Steven Pemberton, W3C/CWI, Amsterdam, The
Netherlands
Researcher at CWI in Amsterdam (first non-military internet site in Europe - 1988, whole of Europe connected to USA with 64kb link!)
Co-designed the programming language ABC, that was later used as the basis for Python
Wrote some of the Gnu C Compiler gcc in the 80's
Organised 2 workshops at the first Web conference in 1994
Chaired the first style and internationalization workshops at W3C.
Co-author of HTML4, CSS, XHTML, XML Events, XForms, RDFa, etc
Activity lead of W3C HTML and Forms Activities, co-chair of XHTML2 Working Group
After a decade of experience with HTML Forms, we knew more about what we need and how to achieve it.
When HTML was first introduced, many people mistook it for a presentation language.
Unfortunately, so did the browser makers, and they introduced tags like
<font> and <blink>, not understanding
that <h1> didn't mean big and bold but meant
This is the top-level heading.
CSS was an emergency attempt to get HTML back to how it was intended, a structure description language.
But still it was a lot of work to get the message over, and even Netscape opposed CSS for a long time, saying you could use script to achieve the same results. (This may have been because the code base couldn't support CSS, and would mean rewriting the browser :-) ).
But still, it took the web community a long time to get it, and understand why separating content and presentation is a better solution than presentation-oriented markup.
Examples:
Compare the following examples from csszengarden, all using the same HTML, but different stylesheets:
People in general are quite concrete, and it takes a while to understand new abstractions.
HTML Forms is an example of this too: it is very presentation-oriented, and it mixes up presentation, function, and data values, all in one markup.
XForms has been designed based on an analysis of HTML Forms, what they can do, and what they can't, and what we actually need.
For instance:
Soundbite: "Javascript accounts for 90% of our headaches in complex forms, and is extremely brittle and unmaintainable."
There are two parts to the essence of XForms. The first is to separate what
is being returned from how the values are filled in. 
The instance specifies the values being collected:
<instance>
<data xmlns="">
<name/>
<birthdate/>
<status/>
</data>
</instance>
It also allows you to initialise the data from an external source:
<instance src="http://example.com/data/t123"/>
By default, all values are of type string. You can assign datatypes to data in the instance:
<bind nodeset="birthdate" type="date"/>
The XForms processor ensures that only valid data is submitted.
You can specify restrictions on values apart from just datatype:
<bind nodeset="year" constraint=". > 1900" />
You can require that values be supplied, unconditionally:
<bind nodeset="name" required="true()" />
or conditionally:
<bind nodeset="state" required="../country='USA'" />
Some values are only relevant depending on other values. There's no point in collecting a credit card number if the person is paying cash:
<bind nodeset="ccnumber" relevant="../method='credit'"/>
You can specify that certain values are calculated from others
<bind nodeset="area" calculate="../height * ../width" />
Finally the model specifies how and where to submit to, and what to do with the result (nothing, display it, put it in an instance).
<submission action="http://example.com/search"
replace="instance"/>
You can regard the model, collecting as it does the data, the types, restrictions and calculations as a sort of 'datasheet', describing the data to be used by the form.
The second part of the essence of XForms is that the form controls, rather than expressing how they should look (radio buttons, menu, etc), express their intent ("this control selects one value from a list").
You then use styling to say how they should be represented, possibly with different styling for different devices (as a menu on a small screen, as radio buttons on a large screen).
Colour: red green blue
Another side to the abstraction is that controls bind to data values in an instance
<input ref="birthdate">
<label>Date of birth</label>
</input>
and so they know about the data they bind to. The system can provide a date picker without any work from the author.
The XForms engine keeps all calculations up to date as input values change, just like a spreadsheet.
The XForms Approach means there are several unusual use cases
Configuring hardware is even easier now: instead of the device hosting a web server that can deal with HTML Forms, all it has to do is deliver its configuration parameters as an XML document, and XForms provides the interface.
<instance>
<config xmlns="">
<hostname/>
<domainname/>
<ip/>
<wireless/>
<ssid/>
...
</config>
</instance>
Many petrol stations (pumps, tills, storage tanks, ...) in the USA are configured in this way with XForms.
ref attribute on controls can be any XPath
expression <instance
src="http://www.example.com/shop.xhtml"/>
<title> element in an XHTML document
<input ref="/h:html/h:head/h:title">...
(i.e. the title element within the head
element within the html element, all in the XHTML
namespace)
class attribute on the body element:
<input ref="/h:html/h:body/@class">...
Suppose a shop has very unpredictable opening hours (perhaps it depends on the weather), and they want to have a Web page that people can go to to see if it is open. Suppose the page in question has a single paragraph in the body:
<p>The shop is <strong>closed</strong> today.</p>
Well, rather than teaching the shop staff how to write HTML to update this, we can make a simple form to edit the page instead:
... xmlns:h="http://www.w3.org/1999/xhtml" ...
<model>
<instance
src="http://www.example.com/shop.xhtml"/>
<submission
action="http://www.example.com/shop.xhtml"
method="put" id="change"/>
</model>
...
<select1 ref="/h:html/h:body/h:p/h:strong">
<label>The shop is now:</label>
<item><label>Open</label><value>open</value></item>
<item><label>Closed</label><value>closed</value></item>
</select1>
<submit submission="change"><label>OK</label></submit>
At release XForms had more implementations announced than any other W3C spec had ever had at that stage
There are many different types of implementation:
Many big players have done implementations, e.g.
As you would expect with a new technology, first adopters are within companies and vertical industries that have control over the software environment used. (This is just a selection)
That list is there just to give a taste, but amongst others not mentioned there are at least 3 fortune 500 companies who don't want it to be public knowledge so that their competitors don't get wind of it.
As more industries adopt XForms, the expectation is that it will then spread out into horizontal use.
XSmiles running under J2ME PP
XForms has everything needed for an application:
People are already using XForms for some pretty exciting applications. xport.net who produce FormsPlayer are doing the most interesting stuff, by using SVG as the stylesheet language. They have produced examples such as a world clock, a contacts database, and even Google Maps in XForms!
The interesting thing about this last example is that it is 25K of XForms, compared with 200K+ of javascript...
This is largely thanks to the declarative programming model of XForms, that means that you don't have to deal with lots of the fiddly administrative details.
Bear in mind that empirical evidence suggests that a program that is an order of magnitude larger takes 34 times as much effort; or put the other way, a program that is an order of magnitude smaller costs 3% of the effort...
A company that has been doing Ajax applications since 1999 reported that they were losing programmers to nervous breakdowns. They switched to using XForms instead.
A company that makes room-size machines, with complicated user interfaces normally used 30 people for 5 years to build the user interfaces. When they tried XForms, they did it in 1 year with 10 people!
The advantages of the XForms approach are:
Steven Pemberton: www.cwi.nl/~steven
These slides: from my homepage.
