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

Re: New To Do Lists example online

From: Aaron Reed <aaronr@us.ibm.com>
Date: Thu, 03 Nov 2005 16:12:45 -0600
To: www-forms@w3.org
Message-ID: <dke22a$l2$1@sea.gmane.org>

Sikora, Gary wrote:
> XForms Team,
> 
> 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. 
> 
> 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.
> 
> We all have varying business models. uSoft and other browsers not
> implementing XForms gives others to attempt to make money. Some
> implementations have opened up, while others have not.
> 
> 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.
> 
> How can we fix this?
> 
> Very respectfully,
> Gary Sikora 
> 

Hi Gary,

There may be a lot of debate as to what each processor's strengths are. 
  But that is goodness, I think.  While it may appear like the XForms 
community is disjointed to a new person investigating the available 
implementations for the first time, it also means that there is a XForms 
processor for almost every production scenario (except natively in a 
browser).  Whether it is open source vs. supported proprietary 
solutions, java versus native, client side versus server based, 
multiplatform availability vs. single platform focus, and even some 
mobile solutions, there is something for everyone.

Echoing Leigh, a major stumbling block is interoperability.  But even 
that is improving as time progresses.  There is pretty decent 
communication between the implementations (considering the differences 
in customer sets, geographies, and limited resources) and the WG is 
doing a good job of mediating differences of opinion in regards to 
behaviors and spec interpretations.  Sure, some implementations are 
ahead of the curve like formsPlayer and offer functionality that others 
don't.  But that is good because they are providing much more vision 
towards the future evolution of XForms than people currently focused on 
1.0 foundation work who can't  spare the resources for "wouldn't it be 
nice" types of features.

What I think we, as a community, can really do to help adoption is 
getting involved as early as possible with people seriously evaluating 
XForms as a technology.  Comments like, "Lack of support for basic 
functionality, such as the 'put' method or repeats. This was naturally 
the biggest showstopper" or "We're against, poor quality, incomplete, 
unreliable implementations of those specs. And we're quite annoyed that 
a spec we actually like is crippled by the lack of conformant, 
free-as-in-speech, multiplatform  implementations", if I had to guess, 
are born from people who went the extra mile and read what documentation 
exists, tried to write some forms, and were fed up with things not 
working like they expected.  I don't know an implementation author out 
there who would ignore requests for guidance from frustrated evaluators. 
   I know my fellow Mozilla contributors and I try to respond promptly 
to any query we receive or bug opened against us, especially if it is by 
a person new to XForms.  And I'm sure the other implementors act 
similarly.  And there are many people on this list that offer guidance 
daily to people trying to write XForms and ran into hurdles.  So there 
is quite a few avenues for a XForm evaluator to persue and quite a few 
people willing to help out.  Somehow we just need to get the word out so 
that there aren't users suffering in silent frustration.  And once they 
get help, of course, then there will be one more person out there who 
can answer someone else's questions and possibly recommend XForms as a 
solution.

I think that the XForms community attitude is great and we seem to be 
headed in the right direction.  But as with any movement or team, 
communication is key -> in our case between implementations, between 
users, and between the user and their processor(s).
Received on Thursday, 3 November 2005 22:21:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:02 GMT