W3C home > Mailing lists > Public > www-forms@w3.org > December 2003

RE: Proposal for Extensions to HTML4

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 6 Dec 2003 15:50:37 +0000 (UTC)
To: "Subramanian Peruvemba (PV)" <subramanian.peruvemba@oracle.com>
Cc: www-forms@w3.org
Message-ID: <Pine.LNX.4.58.0312051644130.15535@dhalsim.dreamhost.com>

On Fri, 5 Dec 2003, Subramanian Peruvemba (PV) wrote:
>>> The name is temporary and will probably change at some point.
> The earlier the better.

Agreed. Do you have an alternative name in mind? I've considered several,
but all were at least as confusing ("HTML Forms" seems to refer to HTML4's
forms chapter, "Extended Forms" seems like it would end up being called
"XForms" with the obvious confusion that that would cause, etc).

I would be very interested in suggestions for unambiguous names.

>>> Note that the official W3C XForms 1.0 Basic Profile draft has, as I
>>> understand it, no serious backing.  It consists of XForms with
>>> extremely little removed; for example XPath, XML Events and even basic
>>> XSchema are still required. It thus does not really address the market
>>> that "Basic" specs usually address.
> This is was the kind of argument that created other "compact" markup
> languages for mobile devices and now we know where that went.

Indeed -- we now use "compact" versions of the bigger specifications, such
as XHTML Basic, CSS Mobile Profile, SVG Tiny, and the like. All these
technologies are much smaller than their original. XForms 1.0 Basic
Profile is not much smaller than XForms 1.0 -- it is, as I mentioned
above, almost identical.

> Now there are growing list mobile devices support complete HTML4.0 and
> CSS (Well you know better)

I know of no devices with complete support for HTML4 or CSS.

> somebody. Statements like "XForms is aimed at the specialist form" is an
> assumption (at best) and is a claim by the new proposal that is **not**
> the stated objective of XForms spec.

Whether it is a stated objective or not, it is hard to deny that XForms is
not aimed at the HTML4 authoring world. It is not backwards compatible in
any way, it requires numerous new technologies like XPath, and it
separates parts of the forms in ways quite alien to most authors. These
and other concerns were also mentioned in:


...where it is pointed out that most of the "stated objectives" of the
XForms spec are not actually addressed by the XForms spec in the opinion
of Web browser vendors (who presumably represent the wishes of their
users, the average Joe user and author).

>>> Most XForms demonstrations I have seen have been either local files
>>> editing local files, or remote XForms translated into HTML+JavaScript
>>> on the fly before hitting the client.
> Please look at the XForms (the actual XForms) implementation page and
> follow through to some implementers website. You will find examples
> that are XForms working on user agents.

Oh, I am not denying there are thin client UAs for XForms (indeed I edited
the introduction in response to comments on www-forms to mention this
explicitly). It is interesting to note, though, that several of the names
on the list you mention represent people who have expressed an interest in
the proposal for HTML4 extensions in order to implement XForms on the
client without using substantial JavaScript as is currently required. This
is one of the uses mentioned in the proposal's introduction, in fact.

>>> I would hope that "political statements" would not affect your
>>> judgement of a technology's worthiness.
> Hmm, when it seems to have affected the spec author. It only natural for
> an casual reader.

I don't really understand what you mean by this.

Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 6 December 2003 10:51:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:10 UTC