RE: Is or isn't scripting needed, was RE: XForms vs. Web Forms

Hi Jim,

In my prior posts, I've come out in your camp with respect to 
not bothering to standardize the what-wg material, in part
because I agree with you that if you can get 80%-ish of it in
a weekend, then it's not worth standardizing.  But also, I feel
it fractures the web to create two different "standards" for
the same things.  I find that the what-wg specs don't have
what it takes to eventually 'merge' the efforts in any kind of
clean way.  And it's problematic that some of the key features,
like repeating structures and submitting XML, are half-baked.

But you raise the interesting question of whether we 'need'
a new forms model at all.  The fundamental premise in developing
XForms is that we do need to upgrade the language of the web
to accommodate the use cases that have presented themselves in
the last dozen years.  The thing is that perhaps we mean 'need'
in a different sense than you do. 

One does not 'need' anything beyond machine language to get a
computer to do its work.  So, why do we have more advanced
computer languages that provide object orientation, or 
event-driven processing, or a declarative processing model?

The answer is that we create these constructs to manage the
complexity of creating larger, more sophisticated web applications
that are too difficult to write and maintain using the simpler
languages that we had before.

So, we aren't talking about need in the technical feasibility
sense so much as the practical feasibility sense.

You're right, we don't need a new forms model to continue to
write pizza order forms.  Will that be small, medium or large?
Would you like wings with that?  How about a 2-liter bottle of pop?

But what people are doing with the web, and what people want
increasingly to do on the web, are more complicated things that
they struggle to achieve or cannot achieve in script.

Let's do shopping carts that don't have to round-trip to the server 
to add a row.

Let's do a table of insurance policies with lists of optional 
components for each. Or a list of available resources with tasks
assigned to each, and metadata for each task. Or book authors
and books by each that are available for check-out. Or any other
imaginable nested table construct.

Let's do wizard-like front ends on tax forms, loan applications,
insurance enrolments, etc.

Let's submit XML to the server in the namespace and schema of the 
consuming application so that we don't need a server-side transformer
with super-user access to talk to the real server-side apps and
the XML database.

Let's leverage the declarativeness of XML for expressing processing
requirements whereever possible because it means that design tools
can be created that *understand* more of what the form author is trying 
to achieve.

Let's let form authors express business rules in a declarative fashion
because every time the computing industry offers a declarative mechanism
for doing something, computing power to the people grows exponentially
(to name a few, think of how many people were empowered by spreadsheets; 
think of how many were empowered by being able to write HTML rather than C++).

...

So, in conclusion, is it true that the limitations of what one can
easily do today should define what it means to be a web developer?
Is it really true that the web is this brittle thing that cannot
grow in functionality even if its continually expanding base of users
envisions more sophisticated purposes than its original design permits?

Somehow, I just don't think that's reasonable.  Instead, I think it
is reasonable to believe that the debate right now is really just a
manifestation of growing pains for the web.  

John Boyer, Ph.D.
Senior Product Architect and Research Scientist
PureEdge Solutions Inc.


-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org]On
Behalf Of Jim Ley
Sent: Sunday, March 20, 2005 8:35 AM
To: www-forms@w3.org
Subject: Re: Is or isn't scripting needed, was RE: XForms vs. Web Forms




"Robin Berjon" <robin.berjon@expway.fr> wrote in message 
news:4238C013.7070409@expway.fr...
> (especially given how buggy IE's implementation of Ecmascript is).

JScript has one major bug - (0.07).toFixed(1), other than that, it's 
extremely good and conformant. (especially as it's actually quite hard to 
have conformance problems in ES).  You certainly can't call it buggy.

> On the other hand I think one could get 80%ish compliance (or perhaps in 
> fact more) with WF2 by hacking through a rainy week-end.

Almost certainly not, some things are impossible, some things are in effect 
impossible simply because of them not-scaling to normal sized documents (and 
this includes things like the repeat model, which currently requires 
iterating over every element in the document before the load even fires, 
completely impractical)  If it was true, it shows how completely irrelevant 
these enhancements are, if it's 2 days of scripting to get them to work in 
IE, we certainly don't need the new features, they're obviously bog standard 
things we have already.

>> I'm sorry, but the more I hear about WF2 the less I like it.
>
> Have you read it? I remember seeing an early draft back when XForms was 
> being voted on and not thinking much good about it, but in its current 
> state I find that it is a high-quality specification that does a large 
> part of what people want.

Very few of the issues raised on the list have been addressed, especially 
important ones where the fact it doesn't fall back in legacy browsers have 
gone completely ignored, whilst some things are well specified, they're not 
implementable within the constraints given (in script/behaviours in IE) and 
the Working Group consists of one person who's obviously beginning to 
struggle to keep up and actually get a call for implementations any time 
soon.

> But I'm starting to get sick and tired of seeing good people that share 
> the same fundamental goals and good intentions waste time bickering about 
> competing specs while the RAND and proprietary scourge takes over the 
> world, or prepares to.

The reason we have competing specs I think, is that most people don't 
actually want any of this stuff, we don't _need_ a new forms model, we can 
rub along fine with what we've got, especially when declaritive languages 
are so much harder to understand than scripting ones for most web 
application developers.

> We've got on one side XForms, which is cool, good in many ways, but that a 
> non-neglible part of our community rejects and on the other WF2 which has 
> fewer features but has support from said non-negligible part of this one 
> same community.

I've seen very, very little support for either WF2 or XForms from developers 
anywhere, we don't need either forms technology, spending time on either of 
them inside the current user agents just seems a waste of precious 
developers time.  Plug-ins are different, I have much more support of doing 
it in these, they're done by different companies, producing added-value for 
their customers, they're customers aren't web-developers though, they have 
different needs, and can address different needs.  Here XForms has much more 
value than WF2, but I'm still not completely sure either groups have really 
captured use cases from web-developers - WF2 has yet to publish a single use 
case for example.

Jim.

Received on Tuesday, 22 March 2005 01:10:22 UTC