W3C home > Mailing lists > Public > www-forms@w3.org > November 2005

Re: New To Do Lists example online

From: Victor Engmark <victor.engmark@cern.ch>
Date: Thu, 3 Nov 2005 10:29:06 +0100
To: www-forms@w3.org
Message-ID: <20051103092906.GA21692@imap.cern.ch>

Sikora, Gary:

> FormFaces utilizes AJAX while minimizing round-trips to zero. A response
> to your statement which may or may not meet your needs. I could have
> done this many times over the last couple weeks. But I think the XForms
> problem is much bigger than just us saying, FormFaces can do it. 
> I think we need to re-group and help the end user. There are different
> needs which pose different solutions - we aren't saying FormFaces for
> all, but it is an option.
> I think perhaps part of XForms adoption process problem is implementers
> trying to sell why their's is the best - this is hurting the cause. For
> example, Chiba using AJAX as the silver bullet, the only, best solution.
> While this is great progress for Chiba, there are still pitfalls and
> other solutions have benefits. 

I think the problem is not so much any "competition" between
architectures, but more the fact that most XForms implementations, well,
suck. This is not a flame, it's just what I felt when evaluating most of
the implementations on the W3C XForms site late last year. Things may
have changed a lot since then, but here are some of the problems
- Getting a test case running required a lot of framework setup (e.g.,
Chiba, but IIRC it was not the worst)
- Support for only a single platform (e.g., formsPlayer)
- The website for the product contained no examples, or the examples
provided were trivial. That didn't exactly inspire confidence.
- Closed source. Do I really need to say more?
- Mandatory use of non-XForms elements, in effect pushing lock-in. Come
on, this is proprietary HTML elements all over again!
- Lack of support for basic functionality, such as the "put" method or
repeats. This was naturally the biggest showstopper.
- The interface looked worse than my first GUI (e.g., X-Smiles,

I ended up with Chiba, and I haven't regretted it: After the initial
setup, it has worked very well with most of the XForms functionality.
In addition, the support is great, it's open source, it works on valid
XForms, and it's moving quite fast (bye-bye DENG). Right now Mozilla
XForms looks mighty promising, with good speed and only a couple
blocking bugs.

> There are server-side, plug-ins, stand-alone, and client-side solutions.
> For example, ditching plug-in solutions does nothing but hurt the cause,
> frankly why are we discussing this here - can we stop this. If someone
> wants to do an evaluation across these deployment frameworks and post
> the results, great. Bantering back and forth is not good for the XForms
> cause.

Nobody's ditching anything, but more pointing out drawbacks with the
different approaches. For example, in the presence of a browser and a
browser plug-in with the exact same level of support, why would anybody
choose the plug-in? Some people seem to think that this means these
persons should focus away from plug-ins, but I believe they can survive
by having some desirable feature lacking from other implementations,
such as more complete functionality support or working across platforms.

One "problem" so far is that since nobody agrees on the best way to
create /the/ XForms processor, the effort is very much spread out. But
exploring the possibilities is one of the strengths of open source, and
will eventually lead to something good enough for most people.

> The bottom line is "cost of entry" creates a barrier. If using XForms
> was as free and universal as HTML 1.0, it would be everywhere. While
> there are open solutions such as FireFox, Chiba and FormFaces, the big
> guys such as Oracle, IBM and Novell are going the other way.

Uhm, Novell and IBM are both helping the Mozilla XForms project:

> How can we fix this?

Cost of entry will eventually prove itself to be worth it. Start-ups
will provide some fantastic interfaces with hardly any client-side
scripting, then Google will start using it, and eventually (at the
release of XForms 4.01) PHBs will order their minions to use it. It will
fix itself.

Regarding "free", just leave open source darwinism alone, and see how many
closed source implementations are left when XForms is popular. One of the
benefits of XForms is that it's implementation-agnostic, or should be. As
long as a closed source implementation works with valid XForms, it can be
replaced with minimal fuss by any other supporting the same parts of the
standard. Keep open source at the front of support, and it will win.

Victor Engmark
"To study and not think is a waste.
To think and not study is dangerous."
- Confucius
Received on Thursday, 3 November 2005 09:29:18 UTC

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