Re: XForms Myths Exposed - By Ian Hixie (Opera)

Ah but that's the question -- 99% of which tasks?
the tasks you knew about yesterday? The ones you knew about last
year? The ones you dont know about yet, but that we might
collectively think of next year?

As I tried to outline, XForms defines constructs that people have
by repeated scripting  experiments proved are needed  and
possible in the browser. Put another way,
to invent the notation for a double integral,
A) you need to discover the concept of integration;

B) You need to invent a notation for it--
C) Reason with that notation until you become adept with the
concept which is initially  new and requires many paragraphs to
explain;
D) Having seen the light, get the AHA moment where you realize
that you can apply the concept repeatedly to integrate over
multiple dimensions.


I for one am not going to take on the task of inventing notations
for things not yet known; to steal a line out of Sir Humphrey's
book in yes Minister, "I foresee all kinds of unforeseen problems
there".



>>>>> "Jason" == Jason Eacott <jeacott@hardlight.com.au> writes:
    Jason> I want to see a spec for X-forms that's complete
    Jason> enough that 99% of tasks can be performed WITHOUT
    Jason> script, since it seems unlikely that any Xforms engine
    Jason> in the future will possibly be able to make sense of
    Jason> all the script that could end up as part of an
    Jason> x-form. by that I mean that a browser based
    Jason> implementation of xforms is unlikely to read and
    Jason> understand script targeted at an open office document
    Jason> for example, or some other-modal variety of renderer.
    Jason> if this isnt the case then the second you use script
    Jason> you are no longer x-platform compatible. even relying
    Jason> on css (which lots of xforms I have seen seem to do)
    Jason> will only work in css capable browsers, so the
    Jason> embedding of an Xform inside something like Xhtml will
    Jason> only get you as far as Xhtml compatibility at best. so
    Jason> If you want a truly x-platform x-modal xform (this
    Jason> gets a bit weird since i understand here that the
    Jason> x-form itself is wrapped up in other markup) you need
    Jason> to embed it in some non-specific xml wrapper and then
    Jason> alter the wrapper depending on target platform(with
    Jason> xslt or something presumably). wouldn't it have been
    Jason> better to just bundle up an xform as a discrete unit
    Jason> the could reliably be sent to any device, independent
    Jason> of the wrapper you choose to surround it in? after i
    Jason> don't think there is any guarantee that just because
    Jason> some device can render an x-form that it can also read
    Jason> xhtml? so there is always a chance that the behavior
    Jason> of such a device could be to just ignore any markup it
    Jason> didn't understand, including anything inside it. this
    Jason> is pure specultaion but I hope you see where I'm going
    Jason> with it.
    Jason> 
    Jason> Cheers Jason.
    Jason>  
    Jason> 
    Jason> 
    Jason> 
    Jason> Date sent: Fri, 11 Mar 2005 14:59:26 -0800 To:
    Jason> andyh@agaricus.co.uk Copies to: www-forms@w3.org Send
    Jason> reply to: tvraman@almaden.ibm.com From: "T. V. Raman"
    Jason> <tvraman@us.ibm.com> Subject: Re: XForms Myths Exposed
    Jason> - By Ian Hixie (Opera) Forwarded by: www-forms@w3.org
    Jason> Date forwarded: Fri, 11 Mar 2005 22:59:47 +0000
    Jason> 
    >> >
> As a follow-up to all that has been said here:
    >> 
    >> 
    >> The Web Forms fans' attempt to polarize between XForms and
    >> scripting is unfortunate --- and based on what I've heard
    >> them say about XForms, I'm not willing to judge whether
    >> that is a consequence of ill-will, a specific intent to
    >> drive a personal agenda, or simply miscommunication.
    >> 
    >> The XForms designers ---myself included have always
    >> motivated the XForms design by pointing out how things
    >> that are complex to do on the legacy HTML4 scripting Web
    >> become dramatically easier on the XForms + XHTML
    >> Web. However, in expressing this, and in our focus on
    >> XForms, we may not have communicated our position on the
    >> role of scripting very well.
    >> 
    >> I believe that scripting played a key role on the Web
    >> during the late 90's in helping Web authors discover the
    >> next set of things beyond HTML4 that would like. Since the
    >> script interpreter was built into the browser, advanced
    >> Web programmers could experiment to their heart's'
    >> content, and what's more, even deploy the result of their
    >> experiments to a wide audience to do real-live usability
    >> testing. I believe this to be a first in the somewhat
    >> fledgling field of user interface engineering.  Now that
    >> we have done this level of experimentation, it is time for
    >> the next turn of the crank in "democratizing the web",
    >> namely, opening it up from the software programmers to the
    >> document authors".  What we have done in the XForms design
    >> starting in 2000 was to carefully enumerate the most
    >> common Web programming tasks for which authors have to
    >> resort to scriptig, and built the next generation design
    >> to obviate those explicit programming tasks.
    >> 
    >> Now, does this obviate scriptin? No. Just as HTML4 in its
    >> time obviated the need to write Visual Basic or C++
    >> programs for the simplest client/server tasks, so XForms
    >> eliminates scripting for most commonly asked for use cases
    >> on the Web; to name a few, data validation and dynamically
    >> growing /shrinking collections to name but a few.
    >> 
    >> If and when we move beyond today's somewhat wasteful
    >> debate over trying to place yesterday's technology against
    >> today's, I believe we will have a happy web where XForms
    >> enables the Web developer looking to get his work done
    >> quickly realize his goals, whilst enabling the bleeding
    >> edge Web developer discover the next set of Web needs by
    >> experimenting via scripts.
    >> 
    >> today's debate over "I can write script, who needs a
    >> higher level abstraction" is no different from assembly
    >> programmers in the early days of C compilers complaining
    >> about not needing anything more since they could write
    >> assembler well enough, thank you very much.
    >> 
    >> -- 
    >> Best Regards, --raman
    >> ------------------------------------------------------------
    >> T. V. Raman: PhD (Cornell University) IBM Research: Human
    >> Language Technologies Architect: RDC --- Conversational
    >> And Multimodal WWW Standards Phone: 1 (408) 927 2608
    >> T-Line 457-2608 Fax: 1 (408) 927 3012 Cell: 1 650 799 5724
    >> Email: tvraman@us.ibm.com WWW:
    >> http://almaden.ibm.com/u/tvraman (google:raman+labrador)
    >> AIM: emacspeak GPG:
    >> http://www.almaden.ibm.com/cs/people/tvraman/raman-almaden.asc
    >> Snail: IBM Almaden Research Center, 650 Harry Road San
    >> Jose 95120
    >> 
    Jason>

-- 
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman:  PhD (Cornell University)
IBM Research: Human Language Technologies
Architect:    RDC --- Conversational And Multimodal WWW Standards
Phone:        1 (408) 927 2608   T-Line 457-2608
Fax:        1 (408) 927 3012     Cell: 1 650 799 5724
Email:        tvraman@us.ibm.com
WWW:      http://almaden.ibm.com/u/tvraman      (google:raman+labrador)
AIM:      emacspeak
GPG:          http://www.almaden.ibm.com/cs/people/tvraman/raman-almaden.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120

Received on Saturday, 12 March 2005 00:49:37 UTC