- From: Aaron Reed <aaronr@us.ibm.com>
- Date: Thu, 03 Nov 2005 16:12:45 -0600
- To: www-forms@w3.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 UTC