- 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
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: http://lists.w3.org/Archives/Public/www-forms-editor/2003Sep/0006.html ...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