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

RE: XForms not enough

From: Hanson, Vance ISTA:EX <Vance.Hanson@gems1.gov.bc.ca>
Date: Fri, 09 Jun 2000 12:05:44 -0700
To: "'Rob McDougall'" <RMcDouga@JetForm.com>, www-forms@w3.org
Message-id: <F2413A849CC9D211AC3500805FFE3E97F0281B@swan.bcsc.GOV.BC.CA>
Robert, i agree with your comments.

The other part of the big picture is that large organizations like
Governments (both federal, and state/provincial) are looking for XFORMS to
enable e-forms interoperability between government to business, government
to citizen, and government to government.

We also hope that the XFORMS group is working with the PKIX standards forum
and the Workflow Management Coalition Workflow interoperability standards.

Thanks
Vance Hanson
Project Manager
Information, Science and Technology Agency
Province of British Columbia
3rd floor, 563 Superior Street
Victoria, BC, V8W 9V1
ph:(250) 387-0712
fax: (250) 356-9287
email: vance.hanson@gems1.gov.bc.ca 
http://www.ista.gov.bc.ca 

-----Original Message-----
From: Rob McDougall [mailto:RMcDouga@JetForm.com]
Sent: Friday, June 09, 2000 11:01 AM
To: www-forms@w3.org
Subject: RE: XForms not enough


Personally, I don't think you're seeing the bigger picture.

Your point of view seems to be hinged on three key underpinnings:
- availability of thick clients
- if the W3C recommends it, the browsers will follow
- the W3C should address a need for high complexity web applications now

On the first point, while the web clients are becoming thicker, more "thin"
clients are being added every day (phones, TVs, etc.).  XForms has to be
able to address these devices too.  If we make the functionality of XForms
dependent on having a rich browser then we forsake the fastest growing
segment of the web.

Secondly, browser vendors do not always implement W3C recommendations (how
many browsers fully support CSS2?).  The XForms recommendation has to be
attractive to browser implementers as well.  If we pack too much into it
today, browser vendors may decide that it's too much work and not implement
any of it.  We need to walk the line between what consumers want and what
implementers are willing to sign up for.

Thirdly, you seem to wish to write fully featured applications utilizing
just a browser in the near future.  While that's a laudable goal, one has to
walk before one can run.  The technologies you cite (XSchema and XUL) are
intended for a development audience.  That's not the majority of web
authors.  The majority of web authors are HTML people.  XForms is aimed
squarely at this majority.  The HTML authors don't have that ability to do
rich forms without XForms.  The development audience always has JavaScript,
as painful as it sometimes is.  Their need (in my opinion) is not as great.

The XForms recommendation must strike a balance between incrementally
improving HTML forms and maintaining the ability of implementers to
implement the functionality with low cost and on all platforms.  XForms must
also set a path that will eventually lead to where you want to go (rich web
applications), but we're not going to get there in V1.0.

Rob

-----Original Message-----
From: Joe Hewitt [mailto:jhewitt@zenimax.com]
Sent: June 9, 2000 11:47 AM
To: www-forms@w3.org
Subject: RE: XForms not enough


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.  

It's nice that XForms wants to be a clean extension to HTML.  But HTML
sucks.  I have a hard time justifying mediocre solutions in the interest of
lazy developers everywhere. XForms is looking like a mediocre solution.

Developers shouldn't have to be forced to develop application frameworks
entirely in Javascript.  Applications built in Javascript can get complex
and slow enough without having to have the entire framework in Javascript
too.  If the framework were an open standard, it could be implemented
natively in all browsers, and we could build apps that really work.  Look at
Mozilla as an example of this.

W3C should ask itself these questions:

1). Is the web moving towards a thicker client model? Yes.
2). Is it good to build a framework to support that model? Yes.
3). Is it good to build separate technologies that are kludgy when used
together? No.

This leads us to the conclusion that the framework itself should be
integrated.  I know W3C working groups try hard to work together, and that
XForms is working with the XSchema group, but before XForms can continue we
need a working group for an XUL-like language as well.  In fact, I think
XForms should have one working group for the data model, and another working
group for the presentation.

-----Original Message-----
From: John Ky [mailto:hand@syd.speednet.com.au]
Sent: Friday, June 09, 2000 1:06 AM
To: Joe Hewitt
Subject: Re: XForms not enough


My understanding of XForms is only cursory but it appears to me that
XForms will:

+ Need to operate in a heterogeneous environment consisting of devices
other than web browsers - some with limited capabilities.
+ Be simple to use and migrate easily from HTML Forms.

XForms cannot loose sight of its audience in the interest of integration.

Where I would like to see XForms develop is consistency with other
recommendations to improve interoperability.

If XUL/XBL could be used to implement the XForms recommendation
in full (when the recommendation eventuates) then that will surely
demonstrate the flexibility and extensibility of mozilla.  It would further
guarantee a high level of integration while maintaining XForms as a
sufficiently stand-alone technology.

So my argument is that XForms shouldn't become part of a larger
project, but it should be designed in a way that maximises its chances
of being used with or even implemented with other technologies such
as XUL/XBL.

-John
Received on Friday, 9 June 2000 15:06:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:48 GMT