CWI and W3C
Kruislaan 413
1098 SJ Amsterdam
The Netherlands
Steven.Pemberton@cwi.nl
www.cwi.nl/~steven
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
Chair of HTML and Forms working groups
Editor-in-Chief of ACM/interactions.
It's a mess
Usability problems, such as Frames
Accessibility problems
Internationalisation problems.
Device dependence
Need for scripting
XHTML1: The smallest changes necessary to make HTML4 XML compliant.
XHTML2: Take real advantage of XML
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: large parts of XHTML2 already work with 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."
The essence is to separate what is being returned from how the values are filled in.
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 for instance that a control selects one item from a list of items. CSS or similar can be used to provide the necessary presentation.
This way the same XForm can be used across different devices without change.
<model> <instance> <data xmlns=""> <amount/> <method/> <credit> <number/><expires/> </credit> </data> </instance> </model> ... <input ref="amount"><label>Amount:</label></input> ... <input ref="credit/number"> <label>Credit card number:</label> </input>
<model> <instance src="home.xhtml"/> ... </model> ... <input ref="h:html/h:head/h:title"> <label>Title:</label> </input>
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:
<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>
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.
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.
It can talk to web services, using SOAP or XML-RPC; 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:
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.
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 emerging clients such as an Instant
Messenger.
This greatly eases providing forms to a wide audience, since forms only need to be authored once.
First XForms-enabled mobile phone announced by KDDI this year.
Thanks to using XML, there are no problems with loading and submitting non-Western data.
XForms has been designed so that it will work equally well with accessible technologies (for instance for blind users) and with traditional visual browsers.
Open standard: No vendor lock-in! (If you think this is a good idea, join W3C!)
XForms is being used by many large companies, such as
Some 30 implementations known to us, several from big names, such as IBM, Novell, Oracle, and Sun (in Open Office/Star Office); IBM and Novell are jointly implementing XForms as a part of Mozilla. There are native implementations, plugins, server-side implementations, and more.
Regular forms uses
Editing XML
As output transformation
XHTML2: www.w3.org/Markup, and if your company is a member: www.w3.org/Markup/Group
XHTML2 spec (draft): http://www.w3.org/TR/xhtml2
XForms: www.w3.org/Markup/Forms, and if your company is a member: www.w3.org/Markup/Forms/Group
XForms spec: http://www.w3.org/TR/xforms/
Tutorial: XForms for HTML Authors, from XForms page above.
XForms validator: www.xformsinstitute.com/validator