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

Re: AW: XForms-processor as applet

From: Ashutosh <ashutosh.galande@tatainfotech.com>
Date: Wed, 14 Jun 2000 15:35:36 +0530
Message-ID: <394758F0.F7EA0864@tatainfotech.com>
To: www-forms@w3.org

Undoubtedly it would always be desirable that the support for XForms (or
for that matter any such standard) should be directly there in the
browswers. But its a fact that perfect representation of a fairly
complex(visually as well as functionally) graphic page within all 
existing browsers is still a hard task.

What I mean here by perfect representation is precise placement of
fields and text.

We should bear in mind that the paper based forms are still by far the
most used method and will continue to be so for a furhter few years.

It would be highly beneficial to have a perfect rendering engine
(independent of a browser) that will felicitate coexisting of
pre-printed paper forms and client-printed paper forms (printed from
within the browser etc). I feel it should be possible to print a form
from within a browser that looks exactly the same as its paper based
counterpart and a plugin based approach is better in this regard.


Josef Dietl wrote:
> Hi,
> I agree on the problems, and we already have an implementation path fitting
> all your requirements plus it doesn't require the installation of a
> plug-in. (If you have to install a plug-in, you may as well ask people to
> upgrade their browsers. We want to enable the existing browser population
> right away.) While XForms isn't available yet, we are using our own Forms
> Markup Language which is based on XHTML Modularization.
> Our solution is: we take documents (today in XHTML-FML, as soon as feasible
> XForms) and convert them into HTML4+JavaScript. This conversion can happen
> on the server or in the authoring tool.
> This approach solves the support-by-browser-vendors problem and enables the
> exisiting installed browser base to use enhanced forms right away. The
> approach to gradually load database tables is also in the works, even
> though it's not avilable yet.
> Josef
> --
> Stack Overflow - We Help Increase Your Productivity With XHTML
> Visit http://www.mozquito.org
> > -----Ursprüngliche Nachricht-----
> > Von: www-forms-request@w3.org [mailto:www-forms-request@w3.org]Im
> > Auftrag von schulze@dresden-informatik.de
> > Gesendet: Dienstag, 13. Juni 2000 16:42
> > An: www-forms@w3.org
> > Betreff: XForms-processor as applet
> >
> >
> > Unfortunatly this discussion becomes a bit diverse, so here's my
> > opinion:
> >
> > 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 Wednesday, 14 June 2000 06:03:38 UTC

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