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

Re: XForms not enough

From: Stanley Santiago <stansa@netscape.com>
Date: Fri, 09 Jun 2000 11:35:21 -0700
Message-ID: <394138E9.D7DBB8F1@netscape.com>
To: Neil Walker <neil.walker@mrc-bsu.cam.ac.uk>
CC: www-forms@w3.org

I might be missing something here, but why is there a need to worry
about presentation semantics, XUL in this case, at all ? I was under
the impression that XForms is a presentation and device independent spec
for modelling forms. 

For example, a particular form model might need be be presented in a
Html client, WML client, VoiceXML client or just paper (pdf). Using
X-forms I
can represent all form semantics just once, and then probably use XSLT
to "present" the
form model to multiple clients.

I don't know much about XUL, does that address diverse clients scenarios
as mentioned
above ? Or does it assume HTML/Javascript type clients only ?


Neil Walker wrote:
> Joe Hewitt wrote:
> > I'm really tired of the sort of mediocre technology that we have to work
> > with on the web.
> > The web absolutely needs an integrated set of application building blocks.
> > I'm tired of static, page-driven sites, and the longer we stick with that
> > paradigm, the longer it will take for the web to reach the next level of
> > productivity.
> Is this a political question?  I think perceptions of what "the web
> absolutely needs" rather depends on what you do for a living, and how
> you use the web.  Are the majority of web developers "tired of the sort
> of mediocre technology that we have to work with on the web"?  At this
> point some 60% of all webservers are using Apache, which suggests there
> are probably rather a lot of non-professional-web-designers making and
> running websites, not all of which are valueless.  Should they be
> squeezed out?
> The XUL description at:
>         http://www.mozilla.org/xpfe/dialogs.html
> contains the paragraph:
>         The XML presented to the internal DOM builder will necessarily have
>         platform dependencies. Individual platforms have unique
>         guidelines about, for instance, the placement of OK and Cancel
>         buttons. Windows may also contain grouping elements and other
>         details unique to certain platforms. This is a problem ideally
>         solved by writing one, cross-platform XUI spec defining the
>         window, and a series of platform-specific stylesheets to
>         transform the window into its actual displayable version.
>         Realistically, it will probably often involve maintaining
>         separate XUI specs.
> You wouldn't believe how uninterested I'd be in that "reality".
> If the web is your shop window, you need all the bells and whistles you
> can get, and will be able to pay developers accordingly.  If you offer
> a simple service, you might be willing to trade the extremes of
> flexibility for ease of development (*).
> That said, XUL has, as its 2 main design goals:
>         http://www.mozilla.org/xpfe/xptoolkit/
>         * Make UIs easier to build
>         * Make cross-platform applications easier to build
> So it seems that expressing the XForms presentation layer in standard
> bits of XUL (with attributes for those that want finer control and
> multiple specs) could be worth pursuing.  Certainly XUL has *nothing*
> to say about handling data, so XForms has a lot to contribute in that
> area.
> Yours
> Neil Walker
> --------------------------------------------------------------------
> Neil Walker                     tel:   +44 (0) 1223 330379
> MRC Biostatistics Unit          fax:   +44 (0) 1223 330388
> Cambridge, UK                   email: neil.walker@mrc-bsu.cam.ac.uk
>                                 web:   http://www.mrc-bsu.cam.ac.uk
> --------------------------------------------------------------------
> (*) its why I write cross-platform GUIs in Tcl/Tk, so I can leverage
> someone else's best efforts to sort out native look and feel. (Tcl is
> also a good langauge for CGI scripts if you don't get on with Perl)
Received on Friday, 9 June 2000 14:33:02 UTC

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