Re: XForms Use Case

>
> I think the right thing to do, instead of adopting XForms as a Web
> vocabulary, is to look at how the Web's existing forms language can be
> enhanced to support things that people want to use XForms for. Actually,
> that's already happened to some extent: many of the forms features in
> HTML5, introduced in Web Forms 2.0, are about doing just that.
>
> So we go from a process where developers have spent nine years looking at
the fundamental issues of working with complex infosets, have in that time
explored dozens of potential potential models, and have managed to put
together a generalized MVC environment that works extraordinarily well in a
RESTful environment of mixed heterogeneous data, and the wunderkind of the
WhatWG pop up with a quick and dirty form framework that exists largely
based upon fiat that of course becomes the de facto standard because, hey,
you control the browsers.

May I make a recommendation. I don't think that there is anyone within the
XML community (especially within the W3C) who would not want to help sit
down and hammer out a forms solution that happen to meet both the casual
developer and the enterprise developer. I think most of us on the XForms
side are actively looking at exploring ways of doing just that. I do think,
however, that the general impression that many people have of this process
(speaking as someone who is setting standards within a large federal agency)
is that, as with many other aspects of HTML5, that this preoccupation with
reinventing the wheel to actively exclude XML is frankly getting old and is
throwing away a huge amount of accumulated knowledge about what works and
what doesn't, on the basis of what appears to be ego. Maybe I'm wrong -
maybe HTML5 is brilliant because it is the work of a select group of the
anointed, but I'd be careful of hubris here - it often gets in the way
making sound decisions ... and this is the last that I will say on that
subject.

Kurt Cagle