Re: IBM Position Statement on XForms and Web Forms 2.0

Hi Lachlan,

Hopefully, the comments of the many others have been helpful.  This is 
exactly the dialogue we need to have.  Continuing with that:

1) Why do you say "XForms is also requried to be used within an XML 
document served with an XML MIME type..."?

XForms does not make any requirements on the content type of its host 
document.  One of my products serves XForms in a document with the MIME 
type application/vnd.xfdl.  And the product works in IE and Firefox, and 
there is an alpha version under Safari.  Another of my products implements 
XForms without even serving it to the client by translating to XHTML, 
which works (!) on windows, mac and linux web browsers that don't even 
have the "benefit" of WF2.

So, the first point is that the web is larger than what web browser makers 
choose to implement.  Knowing that, they gave us tools like plugins.


2) Why do you say "text/html is not XML"?

The server-based product I describe above has been shipping for years now, 
and it heavily relies on the fact that browsers do know exactly what to do 
when the HTML content is XHTML compliant.  Starting in 1998, the W3C 
decided to migrate the web toward XML (http://www.w3.org/MarkUp/future/), 
and this stuff *does* work in the browsers!?!


3) When you say "The vast majority of authors don't use XHTML, they use 
HTML", 

I believe you are actually supporting the point I'm trying to make. 
Although we want to lead the way to XML, it is a challenging and long-term 
process.  People won't update their content without a reason.  The more 
reasons we give, the more likely the upgrade.  The more who upgrade, the 
more reasons we can give because ever more interesting tools and 
applications can then be applied to that content to aggregate, to 
syndicate and to consume it in ways we can't even begin to imagine right 
now.


4) When you say "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." 

I believe you are continuing to mislead, as XForms can also be implemented 
in JS only (there is such an implementation).  Please allow XForms all the 
same tools that you allow WF2, at which point you will find there is no 
need for this divergence.


 5) When you say "XForms also fails to provide for graceful degradation in 
current UAs, like WF2 does" 

I believe you have missed a whole segment of this ongoing thread, esp. the 
main #1 highlighted axis mentioned in the IBM position statement.  We like 
the ease-of-authoring features, and we sure wish the proponents of WF2 
would have just joined the XForms WG and contributed because if you had, 
then not only would XForms 1.1 be a recommendation already, but it would 
even have the features that you want in it.

It is just too easy to say <input name="X" type="integer"/> is an 
ease-of-use syntax that implies the creation of an XForms input control 
bound to a node with local name X and a binding between X and the type 
xsd:integer.

So, since we agree with you on this point, maybe you would be interested 
in joining XForms and contributing this feature to the language.  This 
way, you get the syntax we all want, and it gets unified under a 
conceptual model that the author can then graceful scale upward as his 
data modelling needs increase. 

This means that your argument that Amazon or eBay should use WF2 instead 
of XForms disappears because the best of WF2 would become a righteous 
contribution to XForms, and you wouldn't be able to tell the difference. 
Keeping in mind that I am stressing adamantly that the most prevalent of 
UAs to which you referred can absolutely, positively and without a doubt 
handle it when you send it text/html content that happens to be 
well-formed XML.

Cheers,
John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Lachlan Hunt <lachlan.hunt@lachy.id.au> 
Sent by: www-forms-request@w3.org
08/30/2006 09:30 PM

To
John Boyer/CanWest/IBM@IBMCA
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/