XForms and Device independence

The Author Steven Pemberton, W3C/CWI, Amsterdam, The Netherlands

About me

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

Project meeting

HTML Forms: a great success!





Logging in


Configuring hardware

Linksys router

Reading mail

Reading mail

Composing email

Composing email

Etc etc

So why XForms?

After a decade of experience with HTML Forms, we knew more about what we need and how to achieve it.

The role of Abstraction

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.

Abstraction (continued)

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.


Compare the following examples from csszengarden, all using the same HTML, but different stylesheets:

CSSzengarden post
zengarden post
zengarden worm

HTML Forms

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.

What do we want?

For instance:

Problems with HTML Forms

Soundbite: "Javascript accounts for 90% of our headaches in complex forms, and is extremely brittle and unmaintainable."

The Essence of XForms: Separation of Data from Content

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. Separation of values from controls

The Instance

The instance specifies the values being collected:

   <data xmlns="">

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=". &gt; 1900" />


Required values

You can require that values be supplied, unconditionally:

<bind nodeset="name" required="true()" />

or conditionally:

<bind nodeset="state" required="../country='USA'" />


Optional values

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'"/>


Calculated values

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"

The model = 'datasheet'

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 Essence: Abstract or Intent-based Controls

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

Device independence thanks to abstraction

An advantage of this abstraction is that you don't bind yourself to any particular representation.

A good example of this was a demonstration by Oracle of their XForms implementation. They showed the same form (a pizza-ordering form):


Another side to the abstraction is that controls bind to data values in an instance

<input ref="birthdate">
     <label>Date of birth</label>

and so they know about the data they bind to. The system can provide a date picker without any work from the author.

Example with dates

Another date example

Example with maps

Spreadsheet-like calculations

The XForms engine keeps all calculations up to date as input values change, just like a spreadsheet.


Some Use Cases

The XForms Approach means there are several unusual use cases

Configuring Hardware

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.

    <config xmlns="">

Many petrol stations (pumps, tills, storage tanks, ...) in the USA are configured in this way with XForms.

Multilingual example


Multilingual English

Multilingual Dutch

Other examples



'Editing' any XML document


... example

Editing example

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:

Editing XHTML page

... xmlns:h="http://www.w3.org/1999/xhtml" ...
      method="put" id="change"/>
<select1 ref="/h:html/h:body/h:p/h:strong">
<label>The shop is now:</label>
<submit submission="change"><label>OK</label></submit>

The cost of producing applications

According to the DoD, 90% of the cost of software is debugging.

According to Fred Brookes, in his classic book The Mythical Man Month, the number of bugs increases quadratically according to code size: L1.5.

In other words, a program that is 10 times longer is 32 times harder to write.

Or put another way: a program that is 10 times smaller needs only 3% of the effort.

The Size of XForms Applications

Because of the declarative and abstract nature of XForms, they are very much smaller than the equivalent program needed to produce the same result.

Some data suggests that they are around one quarter the size. Using Brookes's metric, that means they are about an order of magnitude easier to produce.

Data point: Big machines

A certain company makes BIG machines (walk in): user interface is very demanding — needs 5 years, 30 people.

This became: 1 year, 10 people with XForms.

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!

Data point: Google maps

Maps in XForms

Google maps as Declarative Application

Although the example shown above is not quite complete, it does more than Google maps does and yet it is only 25Kbytes of code (instead of the 200+K of Javascript).

Remember, empirically, a program that is an order of magnitude smaller needs only 3% of the effort to build.

Data point: applets

A company is producing many small applications using XForms, based on previous Javascript versions.

They report that the code is less than 25% of the original size (so a tenth of the work).

"[The designers] are really happy to not have to use javascript by the way: they like that if things don't work its not their fault :)"

Deployment strategies

There are three basic strategies for XForms deployment:

Native deployment

XForms is implemented in the browser, and the server sends the XForm directly to the browser.

Examples: Firefox, IE with FormsPlayer plugin, XSmiles, Picoforms for mobile phones

Advantages: Simple, direct

Disadvantage: Only failsafe in controlled environments

Server-side deployment

The server looks to see what the client is capable of, and translates the XForm to something suitable - native, HTML+Script, simple pages

Examples: Orbeon, Chiba, Jadu

Advantages: Flexible, reaches everyone

Disadvantages: Extra infrastructure

Scripted deployment

The XForms contains a single line of script that loads a library that implements XForms.

Examples: Ubiquity, Formfaces

Advantages: Flexible, can be made to work both natively with the Javascript as fallback

Disadvantages: Doesn't work if Javascript is turned off.


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)

... users

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.

Mobile: XForms on an IPAQ

XSmiles running under J2ME PP

XSmiles on an Ipaq

XForms on a KDDI phone

Japanese announcement

Screens of Japanese Phones


Japanese phones


Japanese phone architecture, showing use of XForms

XForms (Picoforms) on a Nokia 9300

XForms running on a Nokia 9300

XForms (SolidApp) on a Sony Ericsson phone

XForms on a mobile phone

XForms on lots of phones (Picoforms again)



The advantages of the XForms approach are:

More Information

Steven Pemberton: www.cwi.nl/~steven

These slides: from my homepage.