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

ok, cool. well lets hope that Xforms manages the trasitional phase
and doesn't get Gzumped by infopath & the rest of the Microsoft mess.


Date sent:      	Fri, 11 Mar 2005 19:15:14 -0800
To:             	jeacott@hardlight.com.au
Copies to:      	tvraman@us.ibm.com
Subject:        	Re: XForms Myths Exposed - By Ian Hixie (Opera)
Send reply to:  	tvraman@almaden.ibm.com
From:           	"T. V. Raman" <tvraman@us.ibm.com>

> 
> XSL has achieved what it has thanks to EXSLT which is where folks
> implement the extensions they want, and guess what, early
> versions of the experiments are sometimes even implemented in
> scripts.
> It's again another good example of new constructs being
> experimented with.
> 
> 
> >>>>> "Jason" == Jason Eacott <jeacott@hardlight.com.au> writes:
>     Jason> XSL has managed to allow just about anything you want
>     Jason> to acheive without resorting to scripting. (even
>     Jason> though it is an option, its just not nececarry for the
>     Jason> most part) I'll be happy with X-forms when it acheives
>     Jason> the same sort of independence from script.  at the
>     Jason> very least I would like to see a full DOM or DOM like
>     Jason> set of tools for proper manipulation of the model via
>     Jason> pure xforms (ie not with script).  I would also REALLY
>     Jason> like to see some way of using the that same toolset to
>     Jason> dynamically target and manipulate the UI part of the
>     Jason> form too!  if that ever exists I think Xforms would be
>     Jason> fantastic.
>     Jason> 
>     Jason> Jason.
>     Jason> 
>     Jason> 
>     Jason> Date sent: Fri, 11 Mar 2005 16:49:18 -0800 To:
>     Jason> jeacott@hardlight.com.au Copies to:
>     Jason> tvraman@us.ibm.com, www-forms@w3.org Subject: Re:
>     Jason> XForms Myths Exposed - By Ian Hixie (Opera) Send reply
>     Jason> to: tvraman@almaden.ibm.com From: "T. V. Raman"
>     Jason> <tvraman@us.ibm.com>
>     Jason> 
>     >>
> > 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
>     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

-- 
Jason Eacott
Hardlight Interactive
http://www.hardlight.com.au

Support bacteria - they're the only culture some people have.

Received on Saturday, 12 March 2005 06:22:12 UTC