Re: IBM Position Statement on XForms and Web Forms 2.0

Hi Lachlan,

Even if I agreed with every point you make below about how this can't be 
done because of such and such statement in this spec or that, we are still 
left with the immutable fact upon which all can agree:

Some kind of collosal mistake has been made.  You propose that one way to 
fix it is to create a schism of long-lasting incompatibility.

I propose the alternative of everyone taking a step back and a deep breath 
and writing some errata to fix the problems rather than throwing out the 
baby with the bathwater.

For example, anyone who said all of the following:
1) "XHTML is an XML language" 
2) "XHTML can be classified as a particular mimetype M"
3) "XHTML+something cannot be classified as mimetype M"

should probably be the one directly encumbered with writing the erratum. 
Given #1 and #2, #3 categorically does not follow.

But of course, as you pointed out already, there are enough occurrences of 
SHOULD and MAY in the mix for us to have another look at it and say SHOULD 
means do something unless there is a compelling reason to the contrary. 
Since we now have compelling reasons, let's get to the business of fixing 
the problems.

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: public-appformats-request@w3.org
08/31/2006 08:48 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:
> I believe you are reading some specs far too rigidly.  Please see the 
> first line of Appendix C of XHTML 1, which says it is informative (as 
> opposed to normative).

I'm aware of that.  But XHTML 1.0, Section 5.1 (which is normative) 
referrs to the Appendix C guidelines as a requirement for labelling the 
documents as text/html.

The XHTML Media Types note (yes, I know it's only informative) states in 
section 3.1 [1]:

   "In particular, 'text/html' is NOT suitable for XHTML Family document
    types that adds elements and attributes from foreign namespaces, such
    as XHTML+MathML"

In section 3.5 (the summary table) the example of XHTML+MathML states 
that it *should not* be served as text/html.  I know that's not quite 
the same as *must not*, but XHTML 1.0, section 5.1 explicitly states 
that text/html may only be used for documents that are "*compatible with 
most HTML browsers*".  MathML or, in this case, XForms is not really 
compatible with HTML UAs, because they require XML processing.

> Second, XHTML is an XML application, which supports namespaces, so why 
> would the guidelines cease to apply because a particular feature of XML 
is 
> used in the XHTML?

It's because the Appendix C guidelines don't apply to XForms, only to 
XHTML that is compatible with HTML browsers.

> Third,  I do appreciate insanity being equated with going against 
> something I might have said :-), except that in this case I was talking 
> about enticing content toward XML well-formedness even when it is served 

> with the type text/html.

But there is significant evidence to show that that simply doesn't work 
in the real world.  XHTML simply cannot be learned or taught correctly 
under text/html condition.  Authors and teachers that try, inevitably 
fail and well-formedness constraints (among others) are frequently 
disregarded.  I've written about this issue before [2].

> Well-formedness constraints don't apply to text/html content right now,
> but it's also not illegal content, and there's nothing unfortunate about 

> delivering XML compliant HTML as text/html.  A host of web browsers 
> (including IE!) have no problems with this content.

The direct irreparable damage it has caused was done a long time ago. 
However, the indirect problems it causes include the following:
* Well-formedness errors aren't fatal and aren't fixed.
* Authors use HTML techniques for scripts and stylesheets
* Authors often fail to comply with the Appendix C guidelines

More of these issues are discussed in [2].

> So, far from my position being an idealistic one, I am actually 
> questioning why the WF2 beliefs against XML are so rigidly held in the 
> absence of any strong technical obstacles.

I'm not against XML and, theoretically, it would be nice to leave HTML 
behind.  However, we must accept the reality that HTML is here to stay. 
There's no reason why it too can't progress along side XHTML (as it does 
in WF2 and WA1 (HTML 5), with the ability to serialise as either HTML or 
XHTML).  We must also give up the myth that XML processing is compatible 
with text/html.

[1] http://www.w3.org/TR/xhtml-media-types/#text-html
[2] http://lachy.id.au/log/2005/12/xhtml-beginners

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