W3C home > Mailing lists > Public > www-forms@w3.org > April 2004

RE: Ian Hickson (Opera) On W3C's XForms

From: Daniel Fowler <daniel.fowler@focus-solutions.co.uk>
Date: Fri, 30 Apr 2004 11:29:30 +0100
Message-ID: <30A02A46CB77D511851900508BAEADBCD1F89C@exchange.focus-internal.co.uk>
To: www-forms@w3.org

Hi All,

What's your take on it? See below.
Do you share Ian's outlook about W3C's XForms? See below.
Are there any better, (to subjective)
faster, (to write?, to execute? to process?)
lighter (HTML Forms :-)) alternatives to W3C's XForms heavy machinery? 


Every so often we get various camps making statements about the various XML
and Internet technologies and it often sparks (interesting) debate. One size
does not fit all and one technology does not (yet) get used in all

Thinking about all the various aspects of modern business and consumer
applications: web browsing, online form filling, implementing business
rules, data storage, data processing, data display, graphing, image
manipulation, web services, printing, process flows, offline working, etc.,
etc., etc. At what point does the operating system become the browser or the
browser the operating system, at what point does the browser become the
application or the application the browser. Rather than focusing on the
technologies and standards and where they are implemented how about focusing
on the business problems and how best to solve them.

The increasing success of electronic web based business in the UK Life and
Pensions market (the area I'm involved with) shows that by adopting readily
available standards businesses can concentrate on improving processes and
thus reduce costs and increase throughput. Despite the fact that the
standards are driven by competitive organisations the result is for the
greater good of the industry.

In comparison a common modern electronic forms technology in the wider
commercial market has not been adopted for the greater good. Thus we have
Adobe (PDF) and Microsoft (InfoPath), dominating the client machines with
commercially competing forms technology. Microsoft and Adobe will use the
open standards when it benefits them but will also promoting their own
technologies (PDF, InfoPath, Avalon/XAML) when it benefits them, after all
they are businesses, what do you expect.

If the dominant players are protecting their own industries, where does this
leave the businesses who are under constant pressure to reduce costs and
needing to automate their paper processes and streamline IT support and
development. Go with the propriety solutions and get vendor lock in, or go
with an open standard that requires technology plug-ins to the common

I think every one in the XForms community believes in the argument for open
standards, and that adopting such standards is for the greater good. The
more businesses that use the open standards the more product developers will
support them, the more choice available to businesses. Choice is
competitive; it reduces costs and promotes innovation. We have choice in our
arena, HTML, XUL, XForms, PDF, InfoPath, Avalon/XAML, etc., makes life
interesting. If XForms gets wide enough support who says it won't be in a
way off future version of Mozilla or IE. One thing is guareeteed in this
industry, never doesn't mean never.

The XForms community also need to address business issues that the Adobe and
Microsoft do address. These issues probably result from the starting point
from which XForms emerged. XForms is the successor (not replacement) to HTML
forms whilst the Adobe and Microsoft solutions are more paper orientated.
Essentially they are solutions to different problems despite appearing
similar on the surface (i.e. rendering in a browser).

The complexity of XForms will be an issue for some solutions. To write a
form in HTML you need to understand, well, HTML, and a little JavaScript
helps. To write a form in XForms you need to understand XML, XML Namespaces,
XML Schemas, XML Events, and XPath and then move onto the hosting syntax,
usually XHTML (big subject itself!), as well as a little JavaScript. A login
screen for a web site is easier to write in HTML than XForms. I.e. it is a
lower cost solution. As the complexity of the HTML form grows the argument
to write it in HTML reduces. In other words XForms is not the solution to
all forms, but it is the possible solution to complex forms. Don't use a
sledgehammer to open a hazelnut. HTML forms will be used because they are
easier to understand than XForms, but XForms are superior for complex forms
problems. However the caveat is that because XForms is more advanced it is
also more complex, and extra complexity may reduce productivity if not used
correctly (or understood correctly).

Essentially XForms is at a higher skill level than HTML and hence,
potentially, a higher maintenance cost for deployed solutions. I.e. HTML is
usable by a wider range of technically competent personnel than XForms.
Current HTML authors would have to skill up, and would the up skill push up
costs. In the modern commercial world where costs are trimmed to the bone
why would businesses switch to a technology that demands potentially higher
Then again once the tools have matured and the complexity of XForms is
hidden from the forms designer are the higher skill fears justified. To a
point yes, you'll always need the car mechanics to fix the engines.

Looking at the printing support, compared to Adobe and Microsoft electronic
forms technologies XForms does not support reproducible printing directly,
in the Adobe and Microsoft solutions it comes for free. Of course printing
is possible with XForms, simply by hitting print button on the browser, or
using transforms to reformat the data model XML into printable format.
However, for some business models the look and integrity of your original
documents is important, and may need to be guaranteed for some solutions.
Another area of weakness for XForms is in application control, particularly
in offline scenarios. All well and good having XForms to capture data.
However, for complex applications where data captured triggers different
processes and routing requirements what happens? We revert back to good
old-fashioned coding.

I believe we need to start providing answers to some of this issues with
future version of XForms if we want to increase the range of solution in
which it can be used. So anyone who promotes XForms should be able to give
answers to the issue of increased technical complexity, reproducible
printing support and business flow control.


-----Original Message-----
From: Gerald Bauer [mailto:luxorxul@yahoo.ca]
Sent: 30 April 2004 08:39
To: www-forms@w3.org
Subject: Ian Hickson (Opera) On W3C's XForms


  allow me to highlight the mailinglist post by Ian
Hickson (Opera) titled "XForms and Mozilla" that
argues that W3C's XForms is bloated committee-ware and
has no future.

  Ian writes:

> 2) Would implementing the [W3C XForms] standard
advance mozilla's mission?

A good question as well. With XForms, the answer is
again no -- the mission of the Mozilla project is to
preserve choice and innovation on the Internet, and to
do this it needs to compete effectively with Internet
Explorer. IE will never implement XForms; Microsoft
have stated in no uncertain terms that the way forward
for IE is Avalon/XAML. Therefore the way to compete
with IE, as far as browser features go, is to provide
technologies that are more attractive to the majority
of Web developers than Avalon/XAML. One key way to do
this is to make the languages easy to use and easy to
author for. XForms is neither: it uses multiple levels
of indirection, multiple namespaces, XML Schema,
XPath, and, probably most importantly, is not
backwards compatible with existing content.

   More @
   What's your take on it? Do you share Ian's outlook
about W3C's XForms? Are there any better, faster,
lighter alternatives to W3C's XForms heavy machinery?

    - Gerald

Gerald Bauer
Open XUL Alliance - A Rich Internet For Everyone |
XUL News Wire | http://news.gmane.org/gmane.comp.lang.xul.announce

Post your free ad now! http://personals.yahoo.ca
Received on Friday, 30 April 2004 06:31:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:13 UTC