XHTML, XForms, and the Mobile Web (original) (raw)

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

Browser

Predicting technology

When you are designing systems to last, you have to take into account likely possible developments.

Predicting technology can be hard

• Lord Kelvin, only a few years before the first flight: "heavier than air flying machines are impossible"
• Scientific American, 1909: "the automobile has practically reached the limit of its development"
• Thomas Watson, IBM, 1940s: "there is a world market for maybe five computers."
• Robert Metcalfe, inventor of Ethernet, 1995, "the Internet will catastrophically collapse in 1996".

Living in an Exponential World

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:

• Bill Gates (maybe) "640k should be enough for anybody"
• A famous professor: "We don't need modems faster than 1200kbs, because people can't read any faster than that"
• My ABC experience
• Recent Mobile Telephone experience

Moore's law

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!

Designing the New Web

What is interesting about the original Web: nothing essentially new, used leverage well.

Why did the WML Web fail? Lack of leverage has to be part of the problem.

There is a problem with having two webs. Imagine if the mobile phone network and the landline phone network couldn't communicate with each other. Compare with the sad state of the instant messenger networks at the moment none of which can interoperate.

Metcalf's law tries to quantify this and says that the value of a network is proportional to the square of the number of its nodes.This means that the value of two non-connected networks is n2+m2, while the value of those two same networks combined as one is (n+m)2, which is essentially twice as valuable. Visually, separate:

Combined:

m+n

| | | | - | | | |

Similarly, three networks combined are worth 3 times more than the three separate.

So we have attempted to design with vision, for a near future. Analyse requirements, specify aims, tried not to reinvent the wheel

Problems with the Web

It's a mess

Usability problems, such as Frames

Accessibility problems

Internationalisation problems.

Device dependence

Need for scripting

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.
• More usability: within the constraints of XML, try to make the language easy to write, and the resulting documents easy to use.
• More accessibility: 'designing for our future selves' – the design should be as inclusive as possible.
• Better internationalization.
• More device independence: new devices coming online, such as telephones, PDAs, tablets, televisions and so on mean that it is imperative to have a design that allows you to author once and render in different ways on different devices, rather than authoring new versions of the document for each type of device.
• Less scripting: achieving functionality through scripting is difficult for the author and restricts the type of user agent you can use to view the document. We have tried to identify current typical usage, and include those usages in markup.

XHTML2

As an example of using generic facilities: it already runs on existing browsers (example)

Except, of course, for XForms and XML Events

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

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 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 supports common use cases

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

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.

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 (though optional) 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.

XForms tries to remain recognisable for HTML community

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

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.

It is internationalized

Because the data submitted is XML, it is properly internationalised.

It is accessible

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

It is not only for forms!

Thanks to the computational possibilities, you can use it for more general applications, such as spreadsheet-style applications, but also much more.

It wasn't principally designed for this, but it just falls out of the design.

It will turn out to be an important use of XForms.

It is royalty-free and unencumbered

An open standard

... with wide industry support

... that is widely implemented.

It is a 'disruptive technology'

(As described in The Innovator's Dilemma by CM Christensen)

Asks a little more of implementations

Initial interest comes from new markets

Existing customers are unlikely to initially appreciate the benefits

Likely to give newcomers to the market a foothold

Mobile

XSmiles now running under J2ME PP

Several things I can't tell you about

Last week, Japanese announcement

...

...

...