Researcher at CWI.
Co-designed the programming language ABC, that was later used as the basis for Python
At the end of the 80's built a system that you would now call a browser.
Organised 2 workshops at the first Web conference in 1994.
Chaired the first style and internationalization workshops at W3C.
Chaired HTML WG for the best part of a decade.
Co-author of HTML4, CSS, XHTML, XML Events, XForms, RDFa, etc.
Forms co-chair at W3C.
XForms, as the name suggests, was originally designed as a replacement for HTML Forms.
The first version did roughly that, but thanks to generality in the design we realised that with small changes it could do much more: you could use it for other applications as well.
The resultant design is XForms 1.1.
A new version XForms 2.0 is in preparation (and features of it are used in the demo)
XForms has input, output, and a processing engine. That's all you need for an application.
Although an application may not look like a form, all it is doing is taking some input from the user, and responding to it, just like a form.
Experience with projects defined with XForms has shown:
Around a ten-times saving in costs, compared with traditional methods.
A certain company makes BIG machines (walk in): user interface is very demanding — traditionally needed 5 years, 30 people.
With XForms this became: 1 year, 10 people.
Do the sums. Assume one person costs ¤100k a year. Then this has gone from a ¤15M cost to a ¤1M cost. They have saved ¤14 million! (And 4 years)
Manager: I want you to come back to me in 2 days with estimates of how long it will take your teams to make the application.
Manager: I want you to come back to me in 2 days with estimates of how long it will take your teams to make the application.
[2 days later]
Manager: I want you to come back to me in 2 days with estimates of how long it will take your teams to make the application.
[2 days later]
Javascript man: I'll need another 30 days to work out how long it will take to program it.
Manager: I want you to come back to me in 2 days with estimates of how long it will take your teams to make the application.
[2 days later]
Javascript man: I'll need another 30 days to work out how long it will take to program it.
XForms man: I've already done it.
Since the 50's computers have become incredibly cheap and powerful, and yet we are still programming them with programming languages that have evolved from languages that were designed to save the computer work.
In fact most computers spend most of their time idle. Here is my computer as I write these slides. The bump at the end is caused by taking the screen shot.
What we need to do (and XForms does) is take the load off the programmer, and put more of it on the computer. Use some of that spare power!
By the 1970's computers were becoming two orders of magnitude cheaper, and programmers weren't: the cost of software was starting to hurt. The term "software crisis" was coined.
The American DoD did some research and discovered that 90% of the cost of software production was in debugging.
Interestingly, Fred Brookes in his book "The Mythical Man Month" reported that the number of bugs in a program is not linear with the length of a program but quadratic:
b ∝ l1.5
Which means: if a program is ten times as long, it has 30 times as many bugs, which means it costs 30 times as much to make.
Conversely, a program that is 10 times smaller costs 3% of the larger program.
And this is the main reason that XForms can produce such savings.
Because (as you will see) you specify what you are trying to achieve and not how to achieve it, there is far less administration to worry about in programs. This means: shorter programs.
How much shorter?
One correspondent in Denmark who was converting a large collections of apps for a company from Javascript to XForms reported that the XForms were about ¼ the size.
So that means we should expect the production time and cost to reduce by one eighth, about an order of magnitude. And indeed we do.
Since version 1.1 XForms is Turing-complete. All of a sudden, people can produce applications, things that didn't look like forms at all.
This is not an XForms tutorial. All I can do is give a flavour of it, and an example.
The essence is to separate what is being returned from how the values are filled in.
Compare this with CSS style sheets: in the head you specify the styling, and in the body you have the content to be styled.
The
model specifies the data being collected and the related
logic:
The data may be pre-populated from local or external sources, and repopulated at any time.
An essential difference with HTML is that XForms controls are intent-based rather than presentation oriented.
Rather than specifying that a control consists of radio buttons, or a menu, XForms specifies what the control does, for instance that it selects one item from a list of items. CSS or similar can be used to provide the necessary presentation.
This approach allows the same XForm to be used across different devices without change, even across very different modalities, such as voice.
The labels may be populated from local or external sources (good for localisation and multi-lingual environments)
Controls are intent-based, by expressing what the control should do, rather than how it should look. So a control can be represented in different ways depending purely on styling.
Here are three identical controls, just styled differently
In this example, nothing has been said about the type of the data being collected (so it gets the default string type):
<instance>
<data xmlns="">
<date/>
</data>
</instance>
...
<input ref="date">...
Here, the control is exactly the same, but the data has been defined as being a date. The control adapts to the type:
<instance>
<data xmlns="">
<date/>
</data>
</instance>
<bind nodeset="date" type="xsd:date"/>
...
<input ref="date">...
Many forms in the world have a field asking which country you come from.
In XForms such data can be kept in a separate file, and updated once, so that all forms that use it get updated simultaneously.
See next slide for an example.
The labels and values can be initialised from external files. So adding a new language to a form is just a case of adding the labels for that language to the external file. You don't have to change the form. This form uses this file. (This is not a part of the design of XForms, but just emerges from the generality of its design).
There are several methods of deployment:
Native (eg Openoffice)
Client-side (eg XSLTForms)
Server-side (eg Orbeon, Betterforms)
Native iPhone implementation:
Thanks to the intent-based controls, the same form can be delivered
without change to a traditional browser, a PDA, a mobile phone, a
voice browser, and even some more exotic clients such as an Instant
Messenger.
This greatly eases providing forms to a wide audience, since forms only need to be authored once.
There are a number of open-source implementations:
XSLTForms is an open-source client-side implementation based on XSLT 1.0 to compile XForms to vanilla (X)HTML and Javascript.
Orbeon Forms, a server-side implementation
The betterFORM project, server-side.
Xfolite is a light-weight XForms client for the J2ME platform. It was originally created at Nokia Research Center.
Many companies use XForms either internally or externally, and have their own implementations, either for internal use or for licensing. For instance:
Examples include:
You have just seen a mapping application written, in little more than 100 lines of code. Not a while to be seen!
In the 50's computers were really expensive, and slow, and programmers as good as free.
Now it is exactly the other way round: computers are as good as free, really fast, and programmers are really expensive.
It is time to make programmers faster too.
I honestly believe that declarative programming like this is part of the future of programming.
These slides are online. If you can't find them, maybe you should be considering a different career.
A tutorial: http://www.w3.org/MarkUp/Forms/2010/xforms11-for-html-authors/
For an overview of all features, elements and attributes of XForms 1.1, see the XForms 1.1 Quick Reference.
It's not easy reading, but the final arbiter in questions of doubt is the XForms 1.1 Specification.
Living XForms 2.0 Draft: http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0
The implementation used for the examples in this talk is the client-side XSLTForms.