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/

Received on Thursday, 31 August 2006 04:31:43 UTC