W3C home > Mailing lists > Public > www-forms@w3.org > July 2003

Re: xforms processors

From: joern turner <joern.turner@web.de>
Date: Tue, 01 Jul 2003 16:54:23 +0200
Message-ID: <3F01A09F.6070007@web.de>
To: Mark Birbeck <Mark.Birbeck@x-port.net>
CC: "'Jagannayakam'" <jagannayakam@aztec.soft.net>, www-forms@w3.org


excellent analysis of the problem.

Mark Birbeck wrote:
> Hello Jagannayakam,
>>I think Forms player works as a renderer . To display a html form that has
>>xform tags. But if the user updates something and submits again the
>>request goes in the form of name&value pairs am i right .
> No. FormsPlayer is a proper client-side implementation of the XForms spec,
> but it just happens to 'run' inside Internet Explorer. So what FormsPlayer
> submits will be whatever the form you have designed tells it to submit. Take
> a look at the XForms specification, and also look at the samples on our site
> (http://www.FormsPlayer.com/).
>>For me i have to talk to xml inteface. So there should be a processor on
>>the client side that changes these name values pair to xml . Thus requires
>>a processor in the server side.
> That is not at all what XForms is all about. You want to deal with XML all
> the way through, so that you can use schemas, namespaces, hierarchy, and so
> on. There is a lot more to it than just transposing name/value pairs into an
> XML document.
>>So when we have a server side processor  there is no seperate need of a
>>client side processor.
> This is something that has been much discussed on this list, and IMO much
> misunderstood. The basis of the misunderstanding is that there is no 'one
> size fits all' solution.
> Obviously the architecture of an XForms processor should be built as a
> client/server application, since that is good programming practice. But the
> question is where should the different pieces be situated?
> If we see an XForms processor as comprising data, a UI and a controller to
> control the interaction between these two pieces, there are a number of
> scenarios that we could adopt:
> 1. The client has all three layers. This is ideal for powerful PCs where we
> want to get the full range of functionality and a fast experience for the
> user. It will usually require a one-off install though - such as a player or
> a new browser.
> 2. The server has both the data and the controller, and the user has a very
> thin UI using a web browser. This approach is ideal for small legacy
> devices, such as mobile phones with WML.
> 3. The server has a data and part of the controller, and the client PC has a
> sub-set of the data, the remaining parts of the controller, and the UI. This
> is optimal for situations where a client install is not possible, but the
> client device is capable of more functionality than a simple phone. This
> approach can dramatically reduce round-trips to the server over option 2.
> Whilst it is the case that a very quick way of getting an XForms processor
> up and running is to take option 2, I feel it will ultimately be options 1
> and 3 that become predominant - mainly for reasons of interoperability.
> (Option 3 is the approach we are taking with our server-side
> implementation.)

Absolutely agree with these points - with a small addition

IMO only option 3 is really flexible enough for real applications cause 
option 1 lacks the possibility of server-side validation. (ok, setting 
aside that there might be some non-networked apps which don't even need 

'no size fits all', so there's room for a lot of different approaches 
each of which may have their relevance for a particular project. option 
3 just offers the most flexibility to fit the different cases.


Joern Turner

> I hope this helps.
> Regards,
> Mark
> Mark Birbeck
> Co-author Professional XML and
> Professional XML Meta Data,
> both by Wrox Press
> Download our XForms processor for IE
> from http://www.FormsPlayer.com/
> Managing Director
> x-port.net Ltd.
> 4 Pear Tree Court
> London
> EC1R 0DS
> E: Mark.Birbeck@x-port.net
> W: www.x-port.net
> T: +44 (20) 7689 9232
Received on Tuesday, 1 July 2003 11:10:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:08 UTC