Re: XForms and Web Forms 2.0

Dharmesh,

> Is there anywhere a list of Fortune 500 / FTSE 100 etc… companies that use
> these technologies.
>
> I guess the proof is in the "eating" i.e. people actually deploying these
> technologies in mission critical applications.
>
> This would be especially helpful to us in pushing Xforms as at the moment it
> feels like we are "flogging a dead horse".
>
> None of the banks we work with seem to be interested, I would especially
> keen to hear of Financial services case studies.

We do have global organisations using formsPlayer, but I think in this
Francisco is right when he talks of using the most appropriate tool
for the job; why would you try to sell XForms in and of itself?
Sometimes XForms is the right thing, and sometimes not, but either
way, surely it's a tool in *your* armoury (if you want to use it), not
your customers'.

Without going into too much detail, if you have a system that uses web
services a lot (for example), then a rich client that can handle
XForms will be ideal. I can only speak for formsPlayer, but that's
where a lot of our use cases are coming from. For example, we have
built a system for a customer that involves using the OpenWFE workflow
engine and the eXist XML database, and we've written no code at all on
the server! All we've done is used a few workflow templates, and the
REST/XQuery interface to eXist, and everything else is achieved via
the XForms themselves. Maintaining such a system is very
straightforward, it's easy to move to other platforms, or to swap
components in and out (since interfaces such as XQuery, are all
standard).

But unfortunately, at the other end of the spectrum, if you have a
system that uses a server-side scripting language, containing direct
querys on a database to populate list-boxes (that whole nineties
thing!) then you might not find XForms that useful. You'll have a
maintenance nightmare with this, either way. For XForms to be of
benefit in this scenario it would have to dramatically improve the
user experience, rather than being 'as good'.

I'm not differentiating here between using client and server
technologies, but rather between the use of high-level constructs
versus painstakingly creating pages with server-side script. So in
this view you will also get productivity improvements if you can use a
pipeline-based system like Orbeon, since it too uses 'big constructs',
even though it delivers HTML to the user.

As you can probably see, what I'm driving at is that at least in the
short term, the main benefits of XForms will accrue to the developers
and not to the users, so trying to 'sell XForms' is probably not only
a waste of time, but unnecessary.

I would disagree with Francisco on one point, though, in that I don't
think this particular debate can be left at the level of 'take your
pick'. The debate surrounding XForms and WF2 takes in the standards
process, the difference between HTML and XHTML, whether the W3C is an
organisation that leads or follows (or confuses), and so on. So whilst
he's right that arguing about right and wrong languages is a waste of
time, it's not a waste of time to argue about whether the W3C should
be host to two different forms solutions, or whether convergance
should be sought instead.

Regards,

Mark

-- 
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Friday, 1 September 2006 16:16:55 UTC