Browser
Steven Pemberton, W3C/CWI, Amsterdam
Chair, W3C HTML and Forms Working Groups
Researcher at the Dutch national research centre CWI
Co-designed the programming language ABC, that was later used as the basis for Python
In the late 80's designed and built a browser, with extensible markup, stylesheets, vector graphics, client-side scripting, etc. Ran on Mac, Unix, Atari ST
Organised 2 workshops at the first Web conference in 1994
Co-author of CSS, HTML4, XHTML, XML Events, XForms, etc
When you are designing systems to last, you have to take into account likely possible developments.
Predicting technology can be hard
As computer technologists, we are lucky to be living in a predictable world
It is surprising how often that predictability is not taken into account:
Take a piece of paper, and divide it into two in the length, and write this year's date in one half
Then divide the other half in two vertically and put the date 18 months
earlier in the top half
Divide the remaining space in two, and put the date 18 months earlier there.
And so on. What this demonstrates is that your current computer is more powerful than all your earlier computers put together!
What is interesting about the original Web: nothing essentially new, used leverage well.
Why did the WML Web fail? Metcalf's law, the problem of two Webs.
Design with vision, for a near future
Analyse requirements
Specify aims
Try not to reinvent the wheel
It's a mess
Usability problems, such as Frames
Accessibility problems
Internationalisation problems.
Device dependence
Need for scripting
In designing XHTML2, a number of design aims were kept in mind to help direct the design. These included (and many are intertwined):
As an example of using generic facilities: it already runs on existing browsers (example)
Except, of course, for XForms and XML Events
Soundbite: "Javascript accounts for 90% of our headaches in complex forms, and is extremely brittle and unmaintainable."
XForms 1.0 was released October 2003
On the day of release there were more implementations than any other W3C specification on the day of release, ever
More than 30 implementations announced so far, including plugins, native implementations, proxies, 'zero install' implementations, a voice-browser, an editor, a validator...
From amongst others IBM, Novell, Sun, Oracle, ...
Implementations include: Openoffice, Mozilla, and 2 or 3 plugins for IE
Leverage: no new servers neededI
Major companies and industries are already using XForms (e.g. Bristol-Myers-Squibb, Frauenhofer, Daiwa - a Japanese Bank, the British Life Insurance industry, US Navy, German Shipbuilding ... and more I can't tell you about yet: watch this space!)
XForms has been designed to allow much to be checked by the browser, such as
This reduces the need for round trips to the server or for extensive script-based solutions, and improves the user experience by giving immediate feedback on what is being filled in.
Because XForms uses declarative markup to declare properties of values, and to build relationships between values, it is much easier for the author to create complicated, adaptive forms, and doesn't rely on scripting.
An HTML Form converted to XForms looks pretty much the same, but when you start to build forms that HTML wasn't designed for, XForms becomes much simpler.
Repeating structures: for instance adding items to a shopping basket, adding items to an expense declaration...
Wizards: exposing successive parts of the form without returning to the server
Multiple submission: submitting the results to different servers
Loading and saving to files
XForms is properly integrated into XML: it is in XML, the data it collects in the form is XML, it can load external XML documents as initial data, and can submit the results as XML.
By including the user in the XML pipeline, it at last means you can have end-to-end XML, right up to the user's desktop.
However, it still supports 'legacy' servers.
Rather than reinventing the wheel, XForms uses a number of existing XML technologies, such as
This has a dual benefit:
XForms tries to remain recognisable for HTML community
Data can be pre-loaded into a form from external sources
Existing Schemas can be used
It integrates with SOAP and XML RPC
Doesn't require new server infrastructure
Because XForms has intent-based controls rather than presentation-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 emerging clients such as an Instant Messenger.
This greatly eases providing forms to a wide audience, since forms only need to be authored once.
Because the data submitted is XML, it is properly internationalised.
XForms has been designed so that it will work as well with accessible technologies (for instance for blind users) as with traditional visual browsers.
Thanks to the computational possibilities, you can use it for more general applications, such as spreadsheet-style applications, but also much more.
An open standard
... with wide industry support
... that is widely implemented.
XSmiles now running under J2ME PP
Several things I can't tell you about
Last week, Japanese announcement
XHTML2 and XForms have been designed to be future-proof, and with device independence in mind, to save the need for two Webs.
For more information on XHTML2 see http://www.w3.org/MarkUp, http://www.w3.org/TR/xhtml2
XForms: http://www.w3.org/MarkUp/Forms, http://www.w3.org/MarkUp/Forms/2003/xforms-for-html-authors.html