XForms and Device Independence (original) (raw)

About me

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

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

So why XForms?

After a decade of experience with HTML Forms, we knew more about what we need and how to achieve it.

The role of Abstraction

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.

Abstraction (continued)

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:

• It is hard to get an overview of a presentation-based page, and very hard to change it without messing up the layout
• For different devices you have to produce different presentation pages, but with stylesheets, you can use the same page, and use different stylesheets.

Compare the following examples from csszengarden, all using the same HTML, but different stylesheets:

HTML Forms

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.

What do we want?

For instance:

• Ease of authoring
• Good user experience
• Ease of changing
• Accessibility
• International
• Device independence - write once, deploy everywhere

Problems with HTML Forms

• Presentation oriented, mixing data, function, 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."

The Essence of XForms: Separation of Data from Content

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 model specifies the values being collected (theinstance), 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

The Instance

The instance specifies the values being collected:

It also allows you to initialise the data from an external source:

Datatypes

By default, all values are of type string. You can assign datatypes to data in the instance:

The XForms processor ensures that only valid data is submitted.

Restrictions

You can specify restrictions on values apart from just datatype:

Example

Required values

You can require that values be supplied, unconditionally:

or conditionally:

Example

Optional values

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:

Example

Calculated values

You can specify that certain values are calculated from others

Example

Submission

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

The model = 'datasheet'

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 Essence: Abstract or Intent-based Controls

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

Example

Colour: red green blue

Device independence thanks to abstraction

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

• On a regular PC
• On a mobile phone
• On a voice browser over the phone
• As an instant messenger buddy

Controls

Another side to the abstraction is that controls bind to data values in an instance

and so they know about the data they bind to. The system can provide a date picker without any work from the author.

Example with dates

Another date example

Example with maps

Spreadsheet-like calculations

The XForms engine keeps all calculations up to date as input values change, just like a spreadsheet.

Example

Some Use Cases

The XForms Approach means there are several unusual use cases

Configuring Hardware

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.

Many petrol stations (pumps, tills, storage tanks, ...) in the USA are configured in this way with XForms.

'Editing' any XML document

• External instances give you immense power

• The ref attribute on controls can be any XPath expression

• XPath lets you select any element or attribute in an XML document

• You can bring in any XML document as instance, even an XHTML document (for instance an XHTML document:)

  <instance **s** **rc="" title="undefined" rel="noopener noreferrer">http://www.example.com/shop.xhtml"**/>

... example

• Binding uses XPath. For instance to bind to the<title> element in an XHTML document
  ...
  (i.e. the title element within the head element within the html element, all in the XHTML namespace)
• or the class attribute on the body element:
  ...

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:

The shop is closed today.

Well, rather than teaching the shop staff how to write HTML to update this, we can make a simple form to edit the pageinstead:

Editing XHTML page

... xmlns:h="http://www.w3.org/1999/xhtml" ... <instance s** rc="http://www.example.com/shop.xhtml"/> <submission **action="http://www.example.com/shop.xhtml"** **method="put"** id="change"/> ... <select1 **ref="/h:html/h:body/h:p/h:strong"**> The shop is now: Openopen Closedclosed** OK

• The page must be correct XHTML (not HTML)
• The server must accept the "put" method (or you can save the result to a file if it is on the local machine)
• (It is examples like this that make the advantages of XHTML over HTML visible)

The cost of producing applications

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.

The Size of XForms Applications

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.

Data point: Big machines

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!

Data point: Google maps

Google maps as Declarative Application

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.

Data point: applets

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 :)"

Deployment strategies

There are three basic strategies for XForms deployment:

• Native
• Server side
• Scripted

Native 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

Server-side deployment

The server looks to see what the client is capable of, and translates the XForm to something suitable - native, HTML+Script, simple pages

Examples: Orbeon, Chiba, Jadu

Advantages: Flexible, reaches everyone

Disadvantages: Extra infrastructure

Scripted deployment

The XForms contains a single line of script that loads a library that implements XForms.

Examples: Ubiquity,Formfaces

Advantages: Flexible, can be made to work both natively with the Javascript as fallback

Disadvantages: Doesn't work if Javascript is turned off.

Implementations

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:

• plugin
• native
• 'zero install' (scripted)
• server-side
• editors
• office suites
• mobile

Implementations

Many big players have done implementations, e.g.

• Novell
• Oracle
• IBM
• EMC
• Cordys
• Sun (on Openoffice/Staroffice)
• Mozilla

Users

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)

• the entire British Insurance industry,
• the US Navy (in submarines),
• NASA (Jet Propulsion Laboratories),
• UK Government (Planning Inspectorate), many UK local government sites
• US Government (eg recovery.gov)
• Verifone - a payment company, for configuring petrol pumps,
• Xerox, for an Enterprise Content Management system, to implement dynamic forms and to do XML binding to editing and adding for Wikis, Blogs, and content management, and another use in active development.
• Yahoo for several internal applications, and now part of their mobile platform
• NACS - the National Association of Consumer Stores for configuring and accessing data from a range of devices,
• Vancity - A Canadian Credit Union, with public XForms-driven pages,
• Daiwa - a Japanese Bank, for a transaction system,
• German Shipbuilders, for configuring ships,
• Fraunhofer (known for MP3) for configuring websites,
• Bristol-Myers-Squibb (pharmaceutical),
• Remia - a major Dutch food manufacturer,
• KDDI: embedded in a Japanese mobile phone,
• US Center for Disease Control: for disease control after hurricane Katrina

... users

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.

Mobile: XForms on an IPAQ

XSmiles running under J2ME PP

...

...

XForms (Picoforms) on a Nokia 9300

XForms (SolidApp) on a Sony Ericsson phone

XForms on lots of phones (Picoforms again)

Conclusion

The advantages of the XForms approach are:

• Device independent applications: Likewise, because of the late binding to the data, you can bind device-dependent interfaces just as easily. (This is comparable with the advantages of using content+stylesheets in conventional XML and XHTML)
• Accessible applications: Because of the model-view-controller approach, it is just as easy to bind an accessible interface to the data as a purely visual one.
• Re-use: If someone develops a widget, like an analogue clock or a map, it is available to all applications, and isn't hard-wired into an app (again, like stylesheets)
• Much less coding: Declarative programming is well known for requiring much less coding, mainly because you don't have to worry about all the fiddly administration involved in traditional procedural programming.