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

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

From: joern turner <joern.turner@web.de>
Date: Fri, 30 Apr 2004 11:35:40 +0200
Message-ID: <40921DEC.9010407@web.de>
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 GMT

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