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

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

From: Victor Engmark <Victor.Engmark@cern.ch>
Date: Fri, 30 Apr 2004 12:42:46 +0200
Message-ID: <3FC7FEE5A901664193468E8F63AFE1EA424CA7@cernxchg15.cern.ch>
To: <www-forms@w3.org>
Cc: "Gerald Bauer" <luxorxul@yahoo.ca>

>    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?

While developing an XForms document the last few weeks, I have made a
few assumptions about the future of this standard:
1. XForms will _not_ replace your ordinary HTML guest book form,
_unless_ making the submission by XForms is easier than the native
scripting language.
2. XForms _will_ replace webshops _if_ any of the major browsers
implement it _according to the standard_. This is where I believe
Mozilla/Opera can win over IE: By being so far ahead in providing
standard compliance that IE will be useless on any but the most ancient
web pages. The big pitfall is whether an XForms document will look the
same in different browsers/viewers; it is definitely not the case today,
but can be avoided by using client- or server-side plugins. More on this
below.

Idea: XForms is supposed to be independent of the mode of presentation,
and therefore it will probably be impossible to make readers converge in
the way they present them. So I propose that in addition to the
standard, XSLT files are made to tailor any XForms document to a
specific mode of presentation. By doing this the XForms themselves can
be presentation independent, while web designers working only on the
visual aspects of pages can stop worrying whether a <repeat
appearance="minimal"...> will look like a table or a list. Just use the
appropriate XSL file.

3: XForms _will_ replace client-side applications for editing XML
documents, simply because it works already, and provides a great deal of
control.
4. XForms _could_ replace a lot of data handling applications, e.g.
Excel, _if_ user defined functions are well supported.

Bottom line: The sky's the limit, but it'll be a hard flight.

Direct comments on Ian's mail:
> [Xforms] doesn't seem to be really suitable for your typical graphical
> (Web) application.

Why? It sure looks good in Chiba (see
http://vengmark.home.cern.ch/vengmark/moi/screenshots/chiba.png).

> > You also have to do validations that could be done on the client
> > and that means crummy performance.
> 
> XForms does not in any way alleviate this since the server can never
> trust the client and therefore has to do all the validation anyway.

This is true for _web_ forms, the kind anyone can have a go at. Not so
for intranet applications and the like, where not trusting the end user
would mean blocking access to the form. This is where XForms 1.0 has a
future, more light-weight versions could be developed for situations
where advanced features are not needed.

> Standards compliance is good if it means interoperability.
> Interoperability is not something that implementing XForms would give
us,
> however, since nobody else in the browser space has implemented it
(and
> several of the other vendors have been quite vocal in their claim that
> they will never implement it).

Yeah, and "64Kb should be enough for anybody". The point is, vendors
will always follow the market potential. Once developers start using
XForms, I believe you will see something like "You need [XForms viewer]
to view this page" all over the Web. Already, DENG and formsPlayer
(http://www.formsplayer.com/) are doing a good job as plugins, X-Smiles
(http://www.xsmiles.org/) is a stand-alone reader, and Chiba
(http://chiba.sourceforge.net/) is almost trivial to integrate with
Tomcat (or any other JSP container) to serve good-looking XForms without
changing the client. And soon vendors will realize that it's better if
they provide native XForms support than handing it over to money-making
plugin developers.

> > and portability is a consequence of XForms design decisions to
address
> > the lack of portability across devices of HTML forms.
> 
> This is extremely misleading. XForms is _less_ portable than HTML
Forms,
> the latter of which are completely device independent. XForms has a
> device-specific profile, for example; HTML does not.

This is wrong. Portability in this case is a measure of whether or not
interface elements are defined abstractly or in terms of device-specific
widgets. 

> More to the point: It's too complicated; it's a bloated
committee-driven
> recommendation that average Web authors do not understand how to
author
> because of its reliance on multiple levels of indirection.

Then I'd like to say something politically incorrect about "average Web
authors", but instead I'll point them to
http://xformsinstitute.com/essentials/browse/ for a bit of reading and
http://www.w3.org/TR/xforms/ for reference.

Of course HTML forms are better supported and more used than XForms
today. XForms became a recommendation of the W3C at the end of 2003,
while HTML forms have been with us practically since the birth of the
Web. Give it some time...

-- 
Victor
Received on Friday, 30 April 2004 06:50:38 GMT

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