Note what neutral observers of this space have to say regarding
XForms and the opportunity presented by a cmbination of Mozilla
and XForms.
I particularly like the firehose analogy:-)
See http://www.cafeconleche.org/#news2004May25

The attached article is by Elliote Rusty Harold (of XML in a
Nutshell, Effective XML, XML Bible, XOM and more fame) and is
part of his live coverage last week's WWW2004 conference in New
York in his Cafe con Leche blog.

As a well-known personality in the XML field --- Elliot sketches
the impact XForms could deliver far better than I could ---
especially given that he is emotionally detached from the
technology unlike myself.

http://www.cafeconleche.org/#news2004May25

Yesterday I wrote about what I didn't like at WWW2004 (the
Semantic Web). Today I'm going to write about what I did
like, because there was one technology presented that
really impressed me, and that I think is going to be a key
part of development in the very near future, with an
exponential growth rate for the next couple of years. That
technology is XForms.

Like many successful technologies before it (XML, HTML,
Java, Linux), XForms doesn't really let you do anything you
can't do today. It is not radically new. It does not
require reorganizing the way one runs a business or
develops software. Unlike the semantic web, it does not
require learning completely new and unfamiliar areas of
technology such as ontologies and inference systems. What
XForms does do is give developers the tools to write a lot
of the applications they're already writing today much more
quickly, cleanly, and robustly.

I'm still learning about XForms, but what I see impresses
me a lot. They are much better designed than HTML forms
ever were. They have been designed with usability,
accessibility, and internationalization in mind (not that
any of those features ever really sell development tools,
but they're nice to have when they don't cost you anything
more). More importantly for XForms adoption, they lend
themselves to the writing of clean, powerful code. Many
things programmers really do care about like data
validation are built right into XForms. Previously these
have had to be hacked together with really ugly JavaScript
tricks and server side frameworks. More importantly XForms
are going to enable really new, server-deployed
applications running inside browsers that just can't be
handled in HTML. For instance, one XForm demoed at the
conference essentially embedded a spreadsheet inside an
HTML page. This wasn't done with ActiveX code like in
IE. It was all written with declarative XForms. Up till
now, browser-based applications have had fairly poor user
interfaces limited functionality. XForms changes all
that. You still wouldn't write Photoshop or Quake in
XForms, but you certainly can write a lot of business based
apps for retail, data entry, customer service, and the
like; and this brings me to my next point:

I've seen many businesses standardize on IE over the last
few years because they like using Microsoft's proprietary
technologies for integrating data into their
Intranets. It's easier to develop a lot of applications by
feeding data into grid controls embedded in web pages. They
get richer, more powerful user interfaces that work a lot
better than anything they can achieve with standard
HTML+JavaScript; and they can deploy the app over the
network straight into the browser. It's a very cost
effective, compelling story for a shop that's mostly
all-Microsoft anyway. But with XForms the development
advantage shifts. The same rich interfaces can be prepared
with XForms (or XForms+CSS) even faster. The resulting
applications will be much more robust, and have naturally
greater separation of the data model from the user
interface. (Of course, you can separate the data model from
the user interface in an IE DOM solution as well, but you
have to think about it and work to make it happen. With
XForms, by contrast, you'd have to work pretty hard not to
separate the model from the user interface.) The benefits
are even larger for someone moving from traditional HTML
forms+JavaScript, or PHP, or JSP. You'll still be able to
use all these technologies, but you'll need to use them a
lot less. Much more of the work can be offloaded into the
forms themselves, and the data presented to your
application in a much richer format than
x-www-formurlencoded name=value pairs. XForms won't do
everything, but like XML, they will do a lot more so your
application can do less.

There is one big open question about XForms and that's
implementation. From what I gathered at the conference
there's currently exactly one high quality implementation,
x-port's FormsPlayer, and it isn't open source. Pricing is
of the "Call us, and we'll figure out how much we can shake
out of you" variety. There's a free-beer version for
developers who just want to play with this stuff, but the
cost for widespread deployment is too high. There is one
open source implementation of the spec, Chiba, but it isn't
complete, and the people who should know at the conference
didn't seem too impressed with it. Still, it's at least
worth a look, and might be a good investment of time for
any programmer with the time to spare and an itch to
scratch.

However the holy grail for XForms support is not a browser
plug-in like FormsPlayer, a standalone application like
X-Smiles, or a Java/JavaScript/servlet hack like IBM's
XForms compiler. Rather it's direct support for XForms
built right into the browser. An organization that
installed an XForms aware browser on every user's desktop
could thereafter forget about most installation
hassles. New custom apps could be delivered just by loading
the right web page. I know we've heard this story before,
but XForms looks like the technology that could finally
deliver it. So, how likely is browser based support for
XForms? In IE, not very likely. IE is essentially frozen,
and even a few years down the line Microsoft is really
focused on its own XAML, likely to the exclusion of
competing technologies like XForms. The more likely host is
Mozilla. Mozilla doesn't have the market share IE does,
especially in business, but that's changing. Real XForms
support would give businesses the same
ease-of-application-development incentive to make the
switch from IE to Mozilla that caused them to move from
Netscape to IE several years ago. Mozilla+XForms is a
potential IE killer. Unfortunately, this doesn't look
likely to happen tomorrow. The vendors and developers of
alternative browsers are showing surprising resistance to
XForms. For instance, Opera's Ian Hickson writes:

          For us (the Web browser vendors: Opera,
     Mozilla, and Apple), the "backwards compatible"
     requirement is not really negotiable, because it
     is quite clear that solutions that don't work in
     the market leader's browser won't be accepted by
     mainstream Web developers. I think a lot of
     people in the W3C world are having difficulty
     accepting this, especially given that Microsoft
     have basically said that IE has been end-of-lined
     (it is my understanding that IE in the next
     version of Windows will have no changes to its
     HTML/CSS/DOM/XML implementations and still no
     support for XHTML, and Microsoft have also stated
     that there will be no new separately-downloadable
     versions of IE available anyway, so even if they
     did upgrade it, it would only be used by those
     who upgraded their operating system).

I think what he misses is that XForms is a compelling
enough story to displace IE. Market leaders can be tossed
out. IE displaced Navigator, partially because Microsoft
had the advantage of bundling IE with Windows, but also
because they produced a superior product, at least some
platforms for a few years. It's no longer true that IE is a
better browser than Mozilla, Opera, Safari, and other
competitors. In fact, almost everyone who's tried one or
more of the alternatives agrees that Microsoft is falling
farther behind every day. Microsoft's decision to halt IE
development until Longhorn ships (possibly in 2006,
probably later) is a disaster for them. If Mozilla
implemented XForms quickly, Longhorn would enter a market
in which businesses and developers were already strongly
committed to XForms. XAML instead of hitting the market
like Visual Basic did 15 years ago, would be more like C#,
a day late and a dollar short; a nice idea, but not one
that would offer developers anything they didn't already
have. As Ray Kroc liked to note, and as Bill Gates
undoubtedly knows, when you see a competitor drowning,
shove a fire hose down their throat. IE is drowning. XForms
is a nice, big firehose.



-- 
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman:  PhD (Cornell University)
IBM Research: Human Language Technologies
Architect:    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:        [EMAIL PROTECTED]
WWW:      http://almaden.ibm.com/u/tvraman
AIM:      TVRaman
GPG:          http://www.almaden.ibm.com/cs/people/tvraman/raman-almaden.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120
_______________________________________________
mozilla-layout mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-layout

Reply via email to