RE: XForms for Server Side?

Robert,

I would like to expand upon Mark's last comment - "And in fact you can also think of many uses of XForms where there is no user interface - so they could be set to run *only* on the server, if you wanted"

XForms provides a standard, language-independent method to express form controls.  Whether a browser can render XForms or a server-side engine is used to convert XForms to user agent compatible markup is inconsequential to the importance of XForms.  Instead of determining the worth of XForms based on where engines can be deployed, I believe that the highest gain of adopting XForms is for forms management.  What I see happening is that industry is departing from using HTML 1.0 form controls for new applications because it does not support mulit-device, or perhaps more important, is being replaced by other technologies.  However, the industry is also perplexed on which way to go.  Today, there are several selections that would technology-lock the form application, for example, .Net, Flash or Java Server Faces (JSF).  Though these pose great capabilities, most IT developers stray from closed-architecture solution because of the huge investment expressing their forms in a selected technology may someday need to be re-hosted which is a costly endeavor.  This is because these technologies use object and/or procedural methods to express the form controls. 

XForms changes this by providing a declarative method to express form controls - this is key.  I view XForms enabling reuse of form controls across technology bindings just as SQL enabled reuse of data storage and retrieval alike.  Just as developers are dedicated to the database abstraction layer development, with XForms developers can be dedicated to the interaction abstraction layer.  Whether the XForms is parsed into XHTML, transcoded to WML or SVG, or translated to a form in which .Net, Flash or JSF can use is of no concern to the XForms developer.  These hosting languages can be exchanged throughout time with zero cost to the forms management system.

I realize that XForms was first conceived to minimize the amount of JavaScript that is written million times over around the world by pushing the logic down into the browser.  However, I strongly believe XForms has a much bigger role in terms of total-cost-of-ownership by providing standardization for forms management like what SQL did for data management.  If the browser can natively render XForms, well, an added bonus.

Gary         

 -----Original Message-----
From: 	Mark Birbeck [mailto:Mark.Birbeck@x-port.net] 
Sent:	Thursday, August 28, 2003 17:53
To:	'Robert Simmons '
Cc:	'www-forms@w3.org '
Subject:	RE: XForms for Server Side?


Hello Robert,

> The assertion is that for applications that use client/server model,
> XForms is not appropriate. Can anyone give me ammo to refute this?

The main problem with the argument is the inappropriate definition of client
and server. Most well designed desktop applications will have an element of
client and server about them, all within one machine. An XForms processor is
no exception and in fact the design of XForms lends itself very well to this
kind of split.

So the question is not whether it should be "on the client or the server",
since it needs to be both; you and your questioner are really talking about
where the split should take place. Could the "server" be on a web server and
"the client" be a browser (which you say is possible), or should the whole
thing be on the user's PC (as your colleague believes)?

Which is better will depend on your application, user environment, security
constraints, target devices, distribution issues, and so on. If you have
hundreds of users with WAP phones then you will need a web server solution
since you won't be able to install XForms processors on their phones. On the
other hand if you want a solution that uses SVG and MathML alongside your
XForms then you will need a client-based processor.

But whatever your criteria, it is certainly *possible* to run an XForms
processor split across two machines - all you need is a way to pass events,
which is not that tricky. You say:

> If the event takes place on a web page, then it is all client side.

but there is no reason for this to be the case. In fact, we are working
towards splitting our XForms processor across many machines at the same
time, so the boundaries are actually quite meaningless. And in fact you can
also think of many uses of XForms where there is no user interface - so they
could be set to run *only* on the server, if you wanted.

Regards,

Mark


Mark Birbeck
Managing Director
x-port.net Ltd.

Download our XForms processor for IE6
from http://www.FormsPlayer.com/

Received on Thursday, 28 August 2003 20:31:12 UTC