RE: IBM Position Statement on XForms and Web Forms 2.0

 
Lachlan,

You say "I suspect Ian was referring to the ability to use JavaScript to
enhance the functionality of WF2 extensions in IE, such as this script
currently under development.

https://sourceforge.net/projects/wf2/"

This script under development is no different then what is available under
say Dojo or Yahoo UI or many other frameworks in existence. When I decided
to have my own Xforms implementation I took this in mind, my clients wanted
the use of fancy frameworks and so we decided to have a xforms container
encompassing user defined widgets

Example
<my:controller ref="/address">
	<dojo:widget .... />
	<yui:widget ... />
</my:controller>

http://showoff2.awardspace.biz/pack/pack/examples/dojoTree.html

The other alternative we went for was via the @appearance attribute. Take a
look at some of our demos to see how the co-existence works. Which can be
seen here
http://showoff2.awardspace.biz/pack/pack/examples/dojoRepeat.html

Please note the server is very slow so please be patient! If error
encountered while loading pls reload

Francisco
facileXForms - Really AJAX at heart

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
Of Lachlan Hunt
Sent: 31 August 2006 05:31
To: John Boyer
Cc: public-appformats@w3.org; www-forms@w3.org
Subject: Re: IBM Position Statement on XForms and Web Forms 2.0


John Boyer wrote:
> However, a few choice quotes from Ian on the chairs thread are:
> 
> "Web Forms 2.0 is an XML language" (August 18, 2006)

It is, but it's also an HTML language.  WF2 defines the semantics and
functionality separately from the syntax.  There is both an HTML
serialisation and an XHTML serialisation available.

The HTML serialisation is to be served as text/html and use syntax based on
the SGML syntax of HTML 4.01, but defined to more accurately reflect the
parsing used by current UAs (including IE, Firefox, Opera, Safari and
others).  The XHTML serialisation is to be served with an XML MIME type
(e.g. application/xhtml+xml), using XML syntax and the XHTML 1.x namespace.

> "The first problem with shoe-horning XForms into HTML is that XForms 
> is based on XML, and HTML is not. We can't require an XML-based language"
> (August 17, 2006)

That's not contradictory with the previous statement.  While WF2 allows for
an XML serialisation, it does not require authors to use it. 
Authors may choose to use either HTML or XHTML.

> There were similar contradictions on the technical side of that chairs 
> thread, such as claiming that Web Forms 2.0 works in IE with a plugin 
> but that XForms doesn't (but not giving XForms the benefit of a plugin).

Although you haven't given a direct quote in this case, I suspect Ian was
referring to the ability to use JavaScript to enhance the functionality of
WF2 extensions in IE, such as this script currently under development.

https://sourceforge.net/projects/wf2/

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.

XForms is also requried to be used within an XML document served with an XML
MIME type, such as application/xhtml+xml when embedded in XHTML, which isn't
even supported by IE.  In fact, formsPlayer seems to add support for XForms
in text/html documents, which is obviously non-conformant, because text/html
is not XML!

> Another mystifying claim to me is Raymond's assertion that we would 
> break backwards compatibility of XForms document by *adding* features 
> that unified the best of what Web Forms 2.0 has to offer into XForms.

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.

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.

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.

> We also need to pull together and reexamine, without hyperbole, 
> whether the team can come up with a way to preserve the XML basis that 
> has become the foundation of HTML over the past six years.

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.

> 6) XForms implementations have already demonstrated its viability 
> on-the-wire.

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.

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.

--
Lachlan Hunt
http://lachy.id.au/