W3C home > Mailing lists > Public > www-forms@w3.org > June 2000

RE: XForms-processor as applet

From: Rob McDougall <RMcDouga@JetForm.com>
Date: Tue, 13 Jun 2000 13:43:31 -0400
Message-ID: <311000B0752ED211B61700805F0D6B0901839443@OTTMAIL3>
To: www-forms@w3.org
Actually, the approach you suggest is very similar to the way a couple of
the forms group members have implemented their own processors.  One member
uses JavaScript instead of a Java applet.  Check out
http://www.mozquito.org/.  Another member uses a browser plug-in to
accomplish XForms-like functionality in the browser.  See
http://www.pureedge.com/.  Both approaches work well with current browsers
but in the long run I think everyone can agree that it's best if XForms
support is built directly into the browsers.

WRT the request-response principle not suiting forms, I have to partially
disagree.  Certainly there is a significant number of forms that this
paradigm will handle just fine (after all this is the way HTML forms work
today and there's a non-trivial number of those that are in use today).
Admittedly, forms that dynamically retrieve information based on user input
do not work well in this mode, but they require more infrastructure than web
browsers/web servers/HTML support today.  If I understand you, you're
talking about either doing partial page retrievals from the web server or
doing database access from within the browser.

Addressing the issue of dynamic forms applications is on the group's "todo"
list, but I'm afraid it's outside the scope of V1.0.  We're trying to limit
the scope of V1.0 to something manageable.


-----Original Message-----
From: schulze@dresden-informatik.de
Sent: June 13, 2000 10:42 AM
To: www-forms@w3.org
Subject: XForms-processor as applet

Unfortunatly this discussion becomes a bit diverse, so here's my

I think one drawback of XForms could be missing / late / inaccurate
support by the browser vendors. So did someone ever think about
implementing XForms as an applet that runs in every HTML4-browser? This
applet could retrieve all necessary data (dtd or xml schema + form-data
+ xforms-definition) via http and then render (possibly browserspecific)
html4 using xsl.

I've worked out some ideas about this approach because I also believe
that the request-response principle does not suite well for editing
forms. For instance, if you want to implement flexible editing of a
database table, the underlying data should be gradually transported over
the web: first the browser downloads all initially visible data (plus a
few extra) and requests the remaining as the user scrolls down. All as
XML, of course. 

=> the model- and instance data should be allowed to be declared by url
=> large amounts of instance data should be retrieved gradually
=> the html4 should be generated in respect of the xml-schema or dtd
=> html4-generation should be customizable via different xsl-stylesheets
Received on Tuesday, 13 June 2000 13:44:39 UTC

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