XForms and Device independence
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.
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
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>
</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>
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 :)"
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.
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
The advantages of the XForms approach are:
Steven Pemberton: www.cwi.nl/~steven
These slides: from my homepage.
