Data point: Google maps
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
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.
Co-author of HTML4, CSS, XHTML, XML Events, XForms, RDFa, etc
Activity lead at W3C
The Web is often treated as if it is a new visual space, but that is not how it is intended. The essence of the Web is meaning.
HTML was designed to represent the structure of the document, not its look. An <h1> is the most important heading, not the markup for big fat letters.
Browser manufacturers, not understanding this underlying design principle went and added presentation elements, and basically made a mess of the markup. Looking at typical web page markup nowadays it is hard to extract the true information from it.
This is not to say that the visual is unimportant in the web, it is just subordinate to the meaning, and the two shouldn't be mixed.
One of the first things that W3C did when it started was start a working group on stylesheets.
Stylesheets give you the power to define much better visuals than possible with HTML, and separates them from the markup itself.
And you can create great designs. And the content is inclusive.
Has caused some terribly messy markup (all those <div>s!)
CSS has some shortcomings.
Fine for static pages, but ...
Forms in HTML are very presentation-oriented, and they mix 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, essentially creating the equivalent of style-sheets for the data (you could call them data-sheets, but we call them models).
The model specifies the values being collected (the instance), and their related logic:
The body of the document then binds forms controls to values in the instance.
<input incremental="true" ref="firstname"> <label>First name:</label> </input> <input incremental="true" ref="secondname"> <label>Second name:</label> </input> Your name is: <output class="strong" value="concat(firstname, ' ', secondname)"/>
The data can be initialised within the form:
<instance>
<data xmlns="">
<x>100</x><y>200</y>
<name>Jimmy</name>
</data>
</instance>
or from external data
<instance src="http://example.com/foo?bar"/>
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).
Here is the same control displayed three times with different presentations. Because they are all bound to the same value, if you change one, the others change to match:
<select1 ref="sex">
<label>Gender:</label>
<item>
<label>Male</label>
<value>M</value>
</item>
<item>
<label>Female</label>
<value>F</value>
</item>
</select1>
The major advantage for accessibily of intent-based controls is that you don't have to scrape, and you don't have to guess what the intent is.
In fact you can bind any number of interfaces to the same Forms.
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>
</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.
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.
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.
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!
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.
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 :)"
(True story)
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 30 days to work out how long it will take.
XForms man: I've already done it.
There are three basic strategies for XForms 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
The server looks to see what the client is capable of, and translates the XForm to something suitable - native, HTML+Script, simple pages
Advantages: Flexible, reaches everyone
Disadvantages: Extra infrastructure
The XForms contains a single line of script that loads a library that implements XForms.
Advantages: Flexible, can be made to work both natively with the Javascript as fallback
Disadvantages: Doesn't work if Javascript is turned off.
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.
Although XForms started out as a replacement for HTML Forms, because of its generality, it is a much more an application framework.
The advantages of the XForms approach are:
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.
The implementation used for the examples in this tutorial is XSLTForms.
Steven Pemberton: www.cwi.nl/~steven
These slides: from my homepage.