- From: joern turner <joern.turner@web.de>
- Date: Fri, 30 Apr 2004 11:35:40 +0200
- To: Gerald Bauer <luxorxul@yahoo.ca>
- Cc: www-forms@w3.org
hello, Gerald Bauer wrote: > Hello, > > 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. i cannot agree to this statement (how should i as a lead of a XForms implementation project ;) for the following reasons: (sorry for repeating arguments that have been stated repeatedly) - the mere amount of implementations listed on the W3C homepage seem to speak another language. - if taking our experience, the interest of users is still growing and as XForms is still young i expect this trend to continue. - XForms closes a gap by providing a standards based presentation layer. - of course XForms isn't trivial cause it solves non-trivial problems which are commonly solved by nightmarish scripting or templating languages today which are neither standards based nor maintainable on the long run. > > 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 @ > http://article.gmane.org/gmane.comp.mozilla.devel.layout/1347 it's hard to argue against such a collection of opinions - and that's what this post mainly consists of. *IMO* it's fruitless to discuss with an author that needs explanation of why XML is the common ground for application integration and who calls for backward compatibility in context with web-forms. - these were never designed for the task at hand and calling for backward compatibility here means simply to block any innovation. comparing html forms with XForms is like comparing apples and peaches; if you want to make a fair comparison you have to compare a html form along with all the javascript and css needed to accomplish the same task that a similar XForms fulfills. - and this changes the picture quite a bit; it's hard to implement dependency tracking and constraint handling in javascript (not to speak from a generic solution) in order to reach the same functionality of a XForms and to make this approach in a client-agnostic way. you can get the feeling that XForms is rejected by some people before really getting into it. - from my personal experience as an implementor i understand the concerns about the many standards XForms uses and its tight reliance on these. it definitely makes it a hard task to build a fully conforming processor but some people have already proven that it can be done. it's also true that authors have their difficulties in using XForms cause its simply a very new language and you've to discover usefull patterns to deal with it. - here XForms is no different to other languages; it has a learning curve. but there's also another side: from these re-occuring discussions about XForms usefullness you might infere that the working group is partly responsible for this. of course it's not the task of a working group to explain their work to anyone coming along. but some of the 'frustrations' about XForms are grounded in the poor willingness of the working group to discuss even serious and well-formulated concerns und not to just repeat its justifications of some decisions (that from time to time also may be false). i apologize if i misunderstand the goal of a working group here but i'm convinced the standard would have profited from a bit more open-mindedness here. additionally there are gaps and unclear statements here and there which make the implementors work hard as long as he's not member of the working group himself. > > > 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? if there is i'd like to hear about it but i fear there's nothing up to the task. XForms *is* a heavy machinery and this should be a concern for the working group to work on but you can't build a complete house only with a hammer. - and it's still a 1.0 version so there's room for improvement in the future i guess. of course, this is only my view of the story. Joern Turner -Admin Chiba Project > > - Gerald > > ------------------- > Gerald Bauer > Open XUL Alliance - A Rich Internet For Everyone | > http://xul.sourceforge.net > 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 05:35:25 UTC