RE: XForms vs. Web Forms

I, too, read the whole five pages, and I also cannot come to the
conclusion that it backs the WHAT-WG, particularly if one reads
how it ends.

My own interview for this piece was over 45 minutes, but I suggested
that the author also talk to Steven Pemberton, who mirrored many of
my opinions on these issues.

In essence, the WHAT-WG approach is a band-aid solution created by
people who are not very familiar with the needs of forms applications.

The one aspect of my interview that was preserved was taken a bit
out of context, though not terribly hurtful.  The starting assertion
of the interview was that XForms would be supplanted within the W3C
by the WHAT-WG work (which I do not call 'WebForms' because it is an
inappropriate name).  This is what is by no means decided.  Yes,
the W3C has to consider any submission, and it particularly has to
consider one that attempts to upgrade the primary web language.

But there is a raft of alternatives to consider as well.  

Would they support having two different dialects?  

Do they support a dialect that has so little extensibility that it 
has to use non-valid XML to achieve one of its purposes? 
(And wording of the encouragement to do so comes off as arrogant)

Do they support the hijacking of the W3C process for bringing the 
web to its full potential by supporting a rogue faction of
*W3C members* who do not participate in the relevant working groups?

Anything is conceivable, but support for the what-wg product would 
be symbolic of a fundamental break-down of the W3C given that it has 
already recommended XForms. It's like letting the barnacles steer the boat!

I have an idea.  Why don't we consider for a moment whether a few more
language hacks that admit a few more use cases is really even worth the 
'standardizing'. Perhaps a few parameters for the discussion: 

Let's consider whether it will be possible to rationalize these hacks with 
the language we eventually want to get to in the future. 

Let's consider whether a language that more accurately reflects the intent 
of the form author will translate into design tools that are easier to use 
by those who will find these concepts challenging in any expression. 

Let's consider the value of having the XML for the data to be processed 
appearing in the form in the namespace of the organization that wants to 
process the data.  Is this inherently more useful to server-side processing
of transactions and use of XML-enabled databases than, say, concocting some 
pointy brackets so that the marketing message is that XML is submitted?

Let's consider whether allowing people to express their business rules
in the manner in which they think about them has any merits (is the 
success of the spreadsheet is one of the killer apps of the industry
any indication?)  A revolution? In the eighties, maybe.

Let's consider whether it is of any value for an event-driven system of 
change to be backed by such a declarative model, especially for the 
long term maintainability of forms as both they and the language they are 
expressed in 'evolve' over time.  See the April issue of Dr. Dobb's Journal
for a bit more discussion of this cause-and-effect property of XForms.

Let's consider whether having the variables that represent the state of
the application expressed in the model is of any benefit in capturing
the entire state of an application, not just its code.  Does this have
any benefit to save/reload offline processing?  Does it have any benefit
for transaction security (i.e. 'what you see is what you sign' digital 
signatures)? Does it have any benefit in archival/records management scenarios.

Let's consider whether device-independence and multimodality matter.

Let's consider it is useful to have a common language for expressing the data
processing model of a form regardless of the host language needed to meet
the full spectrum of business requirements on a per-form basis.  Is the
ubiquity of XML technologies for standardizing just the data model a harbinger
of what's coming for XForms?  Well, have we derived any benefit in terms
of interoperability, in terms of human resource availability, in terms of
being able to express more powerful or meaningful applications based on XML?

... 

And then let's consider whether web browser makers should get behind this thing 
so that the web can continue to progress to its full potential rather than
shunting away from the web and into the waiting arms of office suite vendors
to do what they have clearly already shown such a desperation to do with the
web that they are willing to cobble together piles of script in the attempt,
grumbling all the while that there must be a better way.

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 Eric S. Fisher
Sent: Wednesday, March 16, 2005 6:50 AM
To: www-forms@w3.org
Subject: Fwd: XForms vs. Web Forms



I just read this article (all five Web pages) and cannot conclude from it  
that Web Forms 2.0 is the "winner."  I thought the article was a balanced  
comparison with fair reporting of the real issues confronting XForms  
acceptance.

As I said in my earlier post, they are two different specs:  Web Forms is  
backward-looking and more or less automatically compatible with the  
current generation of browsers.  XForms is forward-looking and is more  
concerned with being an open and compatible player in the XML based Web  
services arena than in being compatible with earlier technologies.  In  
order to have XForms capability in current browsers, you have to download  
a plug-in, just like Macromedia Flash, Real Player and Apple QuickTime, to  
name just three.

I see no reason at all to consider XForms a dead end just because it is  
not supported natively in current browsers.  If this were true, Macromedia  
Flash, Real Player and Apple QuickTime would also be limited this way --  
and I have never heard users of any of these technologies complain because  
they had to download a plug-in.

Let's not throw the baby out with the bathwater.  There are a lot of  
people, most especially Microsoft, that would like to see the XForms  
effort fail.  Truly open standards are fundamently incompatible with  
lock-in strategies of any sort.  XForms opens the door to a number of  
truly astounding applications not invented yet, and its openness provides  
the user and developer communities with options for innovation and  
competition that would be unavailable otherwise.  We can go down both  
development paths without losing any momentum on either.  That's the glory  
of the Internet.

Eric S. Fisher

------- Forwarded message -------
From: "Peter Bruhn Andersen" <bruhn.andersen@get2net.dk>
To: www-forms@w3.org
Subject: XForms vs. Web Forms
Date: Wed, 16 Mar 2005 10:03:36 +0100

I've just seen this article
http://news.zdnet.com/2100-9588_22-5581106.html



It 'compares' XForms to the Web Forms 2.0 specification and concludes
that Web Forms is the winner.



I have no knowledge about the Web Forms specification so I would like to
hear what the group thinks about the article. And perhaps more to the
point: Should we keep using XForms or should we switch to Web Forms?



Regards,

Peter



-- 
Important Note:  This e-mail may contain trade secrets or privileged,  
undisclosed or otherwise confidential information.  If you have received  
this e-mail in error, you are hereby notified that any review, copying, or  
distribution of it is strictly prohibited.  Please inform me immediately  
and destroy the original transmittal.  Thank you for your cooperation.

Received on Wednesday, 16 March 2005 18:26:02 UTC