RE: IBM Position Statement on XForms and Web Forms 2.0

 "The fallback idea is an interesting issue, and as I said, one that has for
a long time been on our 'to do' list in the XForms WG. It's pretty
straightforward to do and deserves more attention...but it's not such a big
deal that the WHAT WG needed to write a new spec for it. Adding this kind of
thing to XForms' MVC architecture is a breeze."

While the Dojo framework encourages widget design to gracefully fallback,
Yahoo does not, you either have JavaScript and the right browser spec or you
don't. 

"Indeed we have a formsPlayer one--but there are lots of things you can do
with a C++ plug-in that you cannot do efficiently in script."

Some of the arguments being talked about makes me remember the fuss about
C++ and the hype associated with Object Oriented Approach. Every one wanted
to write their code in C++ just because it was sexy, then came Java now
.NET. Me I stuck with writing in Fortran!, no more language fascist!

Francisco

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
Of Mark Birbeck
Sent: 31 August 2006 15:45
To: public-appformats@w3.org; www-forms@w3.org
Subject: Re: IBM Position Statement on XForms and Web Forms 2.0


Hi Lachlan,

> The idea is that authors can include this script in their pages and 
> the script will simulate the new controls and features, etc. in IE.  
> e.g. By creating a date-picker widget for the new date/time related 
> controls, or by adding support for the repetition model, etc.
>
> This is different from a client-side XForms plugin, like formsPlayer 
> for IE, which requires the user to install it before the page will
function.
>   The approach taken by the WF2 script, however, does not require the 
> user to have installed some plugin locally, it will function as long 
> as they have JS enabled.

That's fine, and as people have mentioned, there are also XForms/Ajax
implementations available. Indeed we have a formsPlayer one--but there are
lots of things you can do with a C++ plug-in that you cannot do efficiently
in script. (If there weren't, why would you bother implementing WF 2.0
natively?)

But I do feel that your comment reflects an old-fashioned view of internet
technologies. No-one would disagree that there are applications that justify
installation, since people are building and installing them every day. What
we're seeing though is that 'ordinary'
desktop applications contain more and more features that are
internet-focused; data is saved and retrieved, online stores are embedded,
newsletters are viewed, and so on. With the installation of XForms
functionality *once* you get to build a large part of your desktop
application using declarative mark-up.

This is not to say that this is the only place for XForms, but to say that
XForms covers a wide range of potential use cases, from simple forms on the
web, to powerful desktop applications. And the different XForms
implementations reflect this--you can go from a server-hosted, zero-install
solution like Orbeon or Chiba, all the way through to the
dockable/transparent/auto-hiding windows and browser toolbars of Sidewinder
and formsPlayer, with plenty of good stuff like FormsFaces and facileXForms
in between.


> XForms is also requried to be used within an XML document served with 
> an XML MIME type, such as application/xhtml+xml...

That's not true. XForms not only does *not* mandate a MIME type, but it
doesn't even mandate a specific host language!


> ... when embedded in XHTML, which isn't even supported by IE.

That's true, although I'm not sure what that has to do with anything.
As it happens it's a good thing really, since it means that an extension
like Sidewinder that supports XHTML documents 'embedded' in the browser (in
the same way as Acrobat, for example) can do so 'properly' by modifying the
Accept header; a server can therefore be sure that it really can deliver
XHTML to the client.


>  In fact, formsPlayer seems to add
> support for XForms in text/html documents, which is obviously 
> non-conformant, because text/html is not XML!

Non-conformant to what, exactly? See previous point about XForms not
mandating any particular host language.


> I believe he meant that XForms cannot be used correctly in text/html 
> documents (despite what the formsPlayer plugin does), and thus 
> documents using XForms would not be compatible the most prevalent user 
> agent (IE) and cannot be used in the vast majority of HTML on the web.

I don't really understand this, although I'm trying. Just so that people
aren't getting the wrong impression here, an XML document does not cease to
be XML just because it is delivered with the wrong MIME type, even though
that is of course bad practice. (This point is significant in relation to
your later assertion that HTML is more widespread than XHTML.)


> XForms also fails to provide for graceful degradation in current UAs, 
> like WF2 does (even in XHTML).  XForms uses elements in a different 
> namespace from XHTML, whereas WF2 extends XHTML and degrades gracefully.

SVG doesn't degrade gracefully either, and the internal combusion engine
didn't 'gracefully' become a steam engine...sometimes it's just time to move
on. However, as I said before, the wide range of XForms implementations
means that you can easily find a solution that fits your particular
use-case, and obviously the type of browser being used by your users will
have an effect on what solution you choose.


> e.g. WF2 uses <input type="datetime" ... />, which degrades to a text 
> field in current UAs, which at least allows a user to type the value 
> manually.  The equivalent control in XForms markup doesn't degrade to 
> anything usable.

That is an interesting point, and is something that I am keen to see
improved in XForms. However, the big difference with XForms is that adding
such features onto a solid MVC architecture is very straightforward, whilst
adding MVC to the WF 2.0 architecture is a lot of work. I'll be illustrating
this shortly, in a blog post I am writing, but it does strike me as odd,
that the one idea that you will find agreement on from Ruby on Rails,
through Struts, to .NET and on to Dojo, is that MVC architecture is a 'good
thing'; why in the world would people using such concepts want to go
backwards to HTML forms when they've spent years trying to escape their
limitations?


> And in the past 6 years, XHTML has failed to take off.  The vast 
> majority of authors don't use XHTML, they use HTML.  Why should we 
> attempt to force authors to move to XHTML, when there is significant 
> evidence to show that it won't work.  Just compare the number of pages 
> served as text/html with the number served as XML, and consider the 
> fact that the most widely used UA doesn't even support XHTML, thus 
> making it virtually pointless to publish XHTML in the real world today.

I'm not sure that this is true. I'll keep an open mind of course, but
factors that make me think that what you say is difficult to prove, and
probably incorrect, are:

  * most web pages will be served by automated systems, not
    hand authored;

  * even of those that are hand authored, a significant number
    will be authored with XML tools, not 'pure' HTML ones;

  * even XHTML pages will be served with the text/html MIME
    type, since that gives the widest browser reach;

  * so to know how many pages are delivered as XHTML you'd
    need to know what systems are doing the delivering--the
    MIME type tells you nothing.

My guess is that a lot of systems are generating pages on the fly on the
server, and are using XML-related tools to do so, and when the page is
ready, the server tacks the text/html MIME type on at the last minute. But
of course I can't prove that, no more than you can prove your view that when
people use the text/html MIME type, they are delivering 'real' text/html
pages.


> Although it may be technically possible to use XForms on the wire, 
> that doesn't make it a good idea to do so in the real world.  You have 
> to consider the target audience of the web application.
>
> Would you seriously consider it possible for web applications like 
> eBay, Amazon, GMail, etc. to begin using XForms today?  No!  Such a 
> move would not be at all compatible with the majority of users.

Our XForms/Ajax implementation sits on top of any Ajax library--so will work
with YUI, Scriptaculous, etc. So if Amazon and GMail can use an Ajax
library, then they can use XForms. It's no big deal.

(Just as an aside, the kind of implementation you mentioned before, where
scripts are used to provide support for WF 2.0 in browsers that don't
provide such support natively is not beyond the abilities of XForms
developers! It's really not that difficult!)


> However, compare that with deploying WF2 on such sites.  The sites 
> would remain usable in current browsers, but with enhanced 
> functionality in new browsers that support the extensions.

The fallback idea is an interesting issue, and as I said, one that has for a
long time been on our 'to do' list in the XForms WG. It's pretty
straightforward to do and deserves more attention...but it's not such a big
deal that the WHAT WG needed to write a new spec for it. Adding this kind of
thing to XForms' MVC architecture is a breeze.

Regards,

Mark

--
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/