W3C home > Mailing lists > Public > public-appformats@w3.org > August 2006

Re: IBM Position Statement on XForms and Web Forms 2.0

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Thu, 31 Aug 2006 15:45:05 +0100
Message-ID: <640dd5060608310745k69fb347ak2493f8d5134e0d94@mail.gmail.com>
To: public-appformats@w3.org, www-forms@w3.org

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.



Mark Birbeck
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
Received on Thursday, 31 August 2006 14:45:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC