Re: Is the browser support for XForms all that critical?

WHY does there have to be server-side XForms?

The whole, IMHO, purpose of XForms on the client side is to remove the entire
issue of spending server cycles on client work.  The information posted from
the client, after the client validates ALL of the XML, *should* be completely
valid XML.

Of course, *any* smart programmer realizes that "valid" XML can be created
from anywhere.  One of the major benefits of sending XML to the server, is
its extremely easy to "validate" the content against a schema.  Any errors
will be quickly found - prior to the server ever processing any invalid
content.

Of course, this requires someone to write a schema to validate the XML
against.  And that task is nontrivial for any production system.

I would postulate that we should let client machines do what they do best -
client work.  We should let server machines do what they do best - serve.
And to communicate between the two - we should use a technology that does a
good job - XML (with schema validation.)  HOW the client gets the form that
it gets in order to generate the XML to the server should not matter - IMHO.

Bob

On Monday 31 May 2004 05:00 am, Mark Seaborne wrote:
> Dmitri,
>
> There is a good selection of server-side implementations of XForms other
> than Chiba. For example:
>
> Oracle (both client and server-side support):
> http://otn.oracle.com/tech/wireless/mobilebrowser.htm
>
> Novell (server-side support, client-side coming soon):
> http://www.novell.com/products/extend/
>
> Orbeon: http://www.orbeon.com/oxf/doc/index
>
> FormFaces: http://www.formfaces.com/main.jsp
>
> X-Toolbox: http://www.hico.com (German language only at the moment - I
> think)
>
> This list is not exhaustive, but gives a flavour of what is available.
>
> All the best
>
> Mark
>
> The information in this email is sent in confidence for the addressee only
> and may be legally privileged.  Unauthorised recipients must preserve this
> confidentiality and should please advise the sender immediately of the
> error in transmission.  If you are not the intended recipient, any
> disclosure, copying, distribution or any action taken in reliance on its
> content is prohibited and may be unlawful.
>
> Origo Services Ltd accepts no responsibility for any loss or damage
> resulting directly or indirectly from the use of this email or the
> contents.
>
> > -----Original Message-----
> > From: Dmitri Khanine [mailto:Dmitri.Khanine@sympatico.ca]
> > Sent: 30 May 2004 05:39
> > To: Gerald Bauer; www-forms@w3.org
> > Cc: Mark Seaborne
> > Subject: Is the browser support for XForms all that critical?
> >
> > Hello Everyone
> >
> > I am a newbie to this list so let me ask a silly question:
> > Why the lack of XForms support by the web browser vendors
> > seen as a showstopper?
> >
> > Let's cosider public internet. Your user has full control
> > over her web browser. Any information coming from "IE 6.0"
> > may have actually been generated by the perl script etc. If
> > it comes form the client - it can not be trusted. If I run my
> > XForms engine on the client machine, the XML being posted to
> > the server needs to be further validated. Do I need to have
> > yet another XForms engine on the server?
> >
> > What happaned to the idea of coexisting with established
> > technologies? Full server side XForms implementation where
> > conventional HTML and JavaScript is generated out of the
> > XHTML template and served to the client requires no
> > modifications to the client's browser whatsoever. This
> > approach also follows the security guidelines where the only
> > mission of the client-side validation is to provide feedback
> > to the user and is duplicated on the server as only the
> > server-side code is reliable.
> >
> > I was able to find only one fully functional XForms
> > server-side engine - the Chiba project. If there is more -
> > please help me find out. Maybe Microsoft will endorse XForms
> > when they see an industry-standard secure and robust XForms
> > engine for .Net platform....
> >
> >
> > Dmitri Khanine,
> > Sr. Developer,
> > Royal Bank Of Canada

Received on Tuesday, 1 June 2004 11:20:39 UTC