BlogAbout MeGalleryLinksContact

Main | PicoForms Releases New Site »

XForms, XForms Tiny and Web Forms 2

There have been a lot of debate about XForms and the whatwg Web Forms 2 initiative. At the moment the subject is hotter than ever since the XForms working group has to be rechartered. In this new charter is a proposal from XForms to create a XForms Tiny version which will assimilate the Web Forms 2 syntax but be convertible to XForms by e.g. a XSLT transformation. Dave Raggett has been a key driver for this and have created a prototype of such a language which is based upon a JavaScript library. This is in short words the history behind a longer discussion on the www-forms mailing list where a comparison has been made between XForms Tiny (as proposed and implemented by Dave Raggett) and Web Forms 2.

I have been a member of the XForms working group through many years now and have to air my concerns for the proposed route in the new XForms charter. Therefore I send a member only mail to the working group which I now choose to publish on my blog:

It seems from the public discussion that we are starting to have a notion of XForms Tiny and XForms Full. For an implementor which have an XForms 1.0 processor this is a problem as the language between tiny and full are very different and will actual require two code bases. This is a problem for implementations which has strict requirements to code size which is the case for mobile solutions. Furthermore a mobile solution is very unlikely to support JavaScript and will not be able to use an open source library since that would require support for not only a JavaScript engine but also the exposure of standard interface, e.g. to the DOM (again this will increase the code base). It is unlikely that customers will understand that XForms Tiny is something completely different from XForms "Full" and that it would not be possible to "just get the tiny profile". In other specification from w3c the difference between full and tiny is usually defined as a logical subset of features (e.g. SVG and CSS).


I have repeatedly asked for a reason we do this XForms Tiny work and have not received a clear answer other than "we do this before somebody else do it for us". But frankly there are lot of open source frameworks out there and even though XFT is really cool and uses many of the same design criteria as XForms did, it seems it has little to do with the work we previously have done in XForms and hence the naming is very misleading.


It is clear the XForms will not be mainstream as HTML Forms and it will never find its way to the "please contact me" form. It is also clear that it is that kind of functionality WF2 tries to enhance which make perfect sense in an evolutionary way. In XForms we provide some pretty complex semantic constructs which enables authors to describe relationships between data and between data and UI. This is what we call the processing model and it is what makes XForms worth while. This processing model makes it possible to declaratively describe entire applications with a rich UI only based upon data. This is the real difference between XForms and Tine/WF2 (e.g. the processing model vs. event based updates) not some syntactic sugar as element names or if the label is inside or outside the form control element and what a repeating structure means. This is also why XForms should not standardize on XForms Tiny as it is put out today but consider a normal w3c profiling of the "full" version.


In the working group we put a lot of effort in discussion political positing of XForms. It seem the original goal has been to replace HTML Forms (which is quite clear as the specification originates from xhtml). Because of the complex design requirements put out for XForms the goal will not be meet simply because XForms *did* fulfill these requirements but as a side effect made the language to complicated for simple use. Attempts to argument that XForms is not complicated by creating examples like a simply search has been put out there on the web. But when it comes down to grasp XForms in entirety we must face the fact that it is complicated but at the same time extremely powerful.
So when we discuss chameleon namespaces because we want to reach out for the simple usecases we are wasting our time. People using XForms understand constructs as namespaces as they will come with an XML background e.g. from XSLT, XPath, XMLSchema, SVG or ... If they do not come with this background it is unlikely that they would choose XForms over something like an open source JavaScript widget library. We should therefore focus on creating the many improvements we really need in XForms to make the users of XForms happier and not try to please a crowd which does not like the smell of XML.

----------------

Post a comment

About

This page contains a single entry from the blog posted on February 7, 2007 10:57 AM.

The next post in this blog is PicoForms Releases New Site.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33