XForms: XML to the Desktop

About me

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.

Problems with the Web

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

Aims

In designing XHTML2, a number of design aims were kept in mind to help direct the design. These included (and many are intertwined):

• As generic XML as possible: if a facility exists in XML, try to use that rather than duplicating it.
• Structure not presentation: use stylesheets for presentation.
• Usability: within the constraints of XML, try to make the language easy to write, and the resulting documents easy to use.
• Accessibility: 'designing for our future selves' – the design should be as inclusive as possible.
• Internationalization: it is a world-wide web
• Device independence: new devices such as telephones, PDAs, tablets, televisions etc. mean that it is imperative to have a design that allows you to author once and render in different ways on different devices
• Less scripting: achieving functionality through scripting is difficult for the author and restricts the choice of user agent.
• Integration with the semantic web: draw the 'clickable web' in to the semantic web.

XHTML2 and backwards compatibility

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)

HTML Forms: a great success!

• Forms have been the basis of the e-commerce revolution
• You find them everywhere on the web

Searching

Buying

Logging in

Configuring hardware

Reading mail

Composing email

Etc etc

• Tracking packages
• calculating currencies
• submitting taxes
• banking
• expenses
• calendars
• blogging
• wiki
• ...

Problems with HTML Forms

• Presentation oriented, mixing data and presentation
• No types, Ping-ponging to the server
• Reliance on scripting
• Problems with non-Western characters
• Accessibility problems
• Hard to make cross-device for single authoring
• Impoverished data-model, no integration with existing streams
• Hard to manage, hard to see what is returned
• No support for wizards and shopping carts etc.

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

XForms: The Approach

The essence is to separate what is being returned from how the values are filled in.

• The model specifies the values being collected (as an XML instance), and their related logic:
  • Types, restrictions
  • Initial values, Relations between values
• The body of the document then binds forms controls to values in the instance

Controls

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.

Very simple example

<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>

Less simple example

<model>
   <instance src="home.xhtml"/>
   ...
</model>
...
<input ref="h:html/h:head/h:title">
   <label>Title:</label>
</input>

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

<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>

• The page must be correct XHTML (not HTML)
• The server must accept the "put" method (or otherwise, you can use 'put' to the local filestore)

XForms improves the user experience

XForms has been designed to allow much to be checked by the browser, such as

• types of fields being filled in
• that a particular field is required
• or that one date is later than another.

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.

It is easier to author and maintain complicated forms

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.

It is XML, and it can submit XML

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.

It combines existing XML technologies

Rather than reinventing the wheel, XForms uses a number of existing XML technologies, such as

• XPath for addressing and calculating values
• XML Schema for defining data types.

This has a dual benefit:

• ease of learning for people who already know these technologies
• the ability for implementors to use off-the-shelf components to build their systems.

It integrates into existing data streams

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.

It is device independent

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.

Phones, screens, architecture

It is internationalized

Thanks to using XML, there are no problems with loading and submitting non-Western data.

It is accessible

XForms has been designed so that it will work equally well with accessible technologies (for instance for blind users) and with traditional visual browsers.

It is royalty-free and unencumbered

Open standard: No vendor lock-in! (If you think this is a good idea, join W3C!)

It has wide industry support

XForms is being used by many large companies, such as

• Bristol-Myers-Squibb (pharmaceutical)
• Hewlett-Packard
• Remia (a major Dutch food manufacturer)
• Frauenhofer (known for MP3)
• Daiwa (a Japanese Bank)
• Verifone (a payment company, for configuring petrol pumps)
• the entire British Insurance industry (via Origo and Polaris)
• the US Navy (in submarines)
• UK Government (Planning Inspectorate)
• German Shipbuilders (for configuring ships)
• KDDI (a Japanese mobile phone manufacturer, embedding it in one of their phones),
• NACS (the US National Association of Convenience Stores, for configuring and accessing data from a range of devices)
• and some more I can't tell you about (yet).

It is widely implemented

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.

It supports new use cases

Regular forms uses

Editing XML

Spreadsheets

Applications

As output transformation

More Information

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