A few months ago an argument broke out in the bugzilla comments for
bug 97806 ("Implement W3C XForms in browser and composer"). I believe
(and 534 votes agree) that XForms would make Mozilla better.
Unfortunately, this bug has been languishing with the "helpwanted"
keyword, making little progress. I'd like to make the case for XForms
and hopefully stir up some buzz for it.
XForms 1.0 became a W3C recommendation on 14 October 2003. It is aimed
at addressing the gap between thin HTML forms and fat GUI apps.
XForms, much like XUL, provides a set of widgets which can be declared
using an XML language. Unlike XUL, the point here is to allow these
widgets to be bound to an XML data format, so that XML based data can
be submitted.
I believe that XForms could actually be the kind of jolt that would
allow Mozilla to get penetration onto some corporate desktops.
Businesses spend unbelievable amounts of money creating and
maintaining apps to capture business data and flow it around to their
various information repostiories. Ultimately, I think Xforms
implemented in the browser could redirect a lot of corporate
development towards the lean interface option between thin and fat
clients. This is the kind of force that could drive Mozilla to a lot
of corporate desktops.
Let me explain why an XML bound data form is so valuable to
corporations. Especially when multiple databases or business services
are being fed, it is very desirable to have the data in an XML format.
Hopefully I don't have to explain why XML makes enterprise application
integration easier. In an HTML form setting, you have to write a lot
of middle-tier code to bind the data elements of a submitted form to
your targetting XML format. You also have to do validations that could
be done on the client and that means crummy performance. XForms is
powerful enough to displace a lot of this work. This is why XForms
leverages so many standards -- the use cases where XForms wins are the
ones where you are doing this stuff anyway, but doing it in the middle
layer with custom code, perhaps in multiple places.
That's the back-end argument. There is a fron end argument too.
Invariably somebody comes along and says "gosh, can we do the data
entry on our mobile devices" and then your have to produce a whole
separate presentation layer which runs up costs. XForms solves this
problem because it is designed to be much more device independent than
HTML forms. Mozilla as the premier flag waiver of the "standards
compliance" movement should understand that we can have a lot of
device vendors as allies if we implement XForms.
I think that Mozilla should ask three questions about itself when a
new standard shows up to figure out if it makes sense to include in
the browser
1) Does the standard have any synergy with mozillas core competency as
an HTML browser?
2) Would implementing the standard advance mozilla's mission?
3) Is there user demand and would that demand possibly increase
mozilla deployment?
All three questions are strongly "yes". 1) is easy: HTML has a simple
type of form because data entry has browser synergy. XForms are just a
more advanced data entry that adds value in settings like the
enterprise application space. To 2) I say Mozilla's mission statement
is to be a browser "designed for standards-compliance, performance and
portability". XForms assists all three: standards compliance is almost
a tautology since XForms is a W3C standards. Performance of the entire
information flow imporves when we move XML tasks to the client to
avoid network round-trips and distribute processing, and portability
is a consequence of XForms design decisions to address the lack of
portability across devices of HTML forms. To 3) I reiterate my points
above about corporate computing wanting XML and I also note that all
kinds of desktop apps for home users do little more than organize data
entry tasks. Clearly people agree because there are 534 votes.
Some people object to XForms. Their arguments seem to be:
A) It's too complicated. It's a bloated committee-created standard
with too many bells and whistles and too little implementation
experience. Big new standards won't be implemented consistently by
vendors and won't have much content for a long time.
B) XForms depends on too many other specs. Implementation is a pain
C) Wouldn't it be better to just incrementally improve HTML forms?
I believe there is some rationality in all of these criticisms, but I
just don't think they are substantial enough to offset any of the
benefits. To A) I say that if XForms, in it's full glory seems too
big, then start by implementing the simplified core of XForms Basic,
or some other subset. Every W3C recommendation has at least two
implementation apps, so I just don't buy that its so complex that that
our weary little brains will melt. There is a healthy base of
implementers out there and a whole community who wants XForms, so who
better to foster dis-ambiguation of the standard than Mozilla. This
applies equally to B)... people wanted to leverage the other specs in
XForms because enterprise application devlepment has to deal with that
level of complexity anyway and if XForms can do more of the heavy
lifting then it adds value. Besides, if XForms didn't need to deal
with XML and all the related specs, then C) might be valid. But C) is
not valid because it contradicts the mozilla mission to be standards
compliant and it wouldn't work anyway unless you can convince IE to
implement the same changes without trying to embrace, extend, and
extingish your improvements. The IE has successfully thwarted
incremental improvements to HTML, get over it. The only arena in which
mozilla can innovate successfully is by incorporating community
supported standards that have synergy with HTML and add large amounts
of new functionality that require open standards. Standards compliance
is the ONLY feature that IE cannot bully mozilla over. Unless mozilla
innovates in the direction of its stregths and its mission (standards,
portability, performance) it cannot compete with IE.
_______________________________________________
mozilla-layout mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-layout
