Re: IBM Position Statement on XForms and Web Forms 2.0

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

XForms defines the host document to be XML and XML documents should be 
served with XML MIME types (or at least a MIME type that is defined to 
use XML processing in some way) in order to be processed as XML.  See my 
previous e-mails that touch on this issue.

> 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.

That's fine.  It's a vendor specific MIME type and you can define it to 
be for whatever you like, including XML content.  Presumably, your 
application knows that it needs to handle the XForms content in a file 
delivered with that MIME type as XML and there is no problem with that.

> 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.

Are you saying that the browser doesn't receive XForms markup at all in 
this case?  Is the system converting the XForms markup on the server to 
XHTML <input>, <select> and <button> elements prior to sending it to the 
client?

If so, that's fine.  How the content is produced on the back end is 
irrelevant to this this discussion.  In fact, if I've understood this 
correctly, your system could even benefit from the proposed controls in 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.

That's true, but any language intended as a replacement for HTML either 
needs to become as widely deployed amongst users, as quickly as 
possible, and to provide adequate fallback mechanisms which will be 
heavily relied upon during the transitional period.

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

Um.  Because it's not!  See earlier in the thread where it was mentioned 
that XHTML documents served as text/html are not treated as XML, but 
rather as any other erroneous HTML document, in tag-soup parsers.

Also, keep in mind that the "XML Data Islands" feature implemented in IE 
is a proprietary, non-standard and non-interoperable extension.  It 
cannot be used as an argument against this because it doesn't really use 
XML processing.  It seems to simulate namespaces by generating a 
proprietary <?xml> SGML-like PI and treats ill-formed markup in the same 
insane way it handles HTML, by building a broken DOM.  In other words, 
it shouldn't even be called "XML" because, although it shares some 
similarities in syntax, it's not treated as such.

> 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.

Are you saying that browsers handle XHTML as text/html any differently 
from HTML?  If so, that is simply not true.  If not, please clarify.

> 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!?!

It may appear to work on the surface, but you really need to consider 
the many significant differences between HTML and XHTML processing, 
particularly in relation to style sheets, the DOM, scripting techniques, 
parsing and whole lot more.

> 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.

But we shouldn't force people to use a new technology by saying if you 
don't, you'll be left behind.  The transition path needs to be as smooth 
as possible.

> 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).

But for such an implementation to function in IE, it needs to be served 
as text/html, which, as I have already stated, is not appropriate! 
Using such a script in browsers that actually support XHTML, however, is 
fine.

> Please allow XForms all the same tools that you allow WF2, at which 
> point you will find there is no need for this divergence.

The divergence happened 8 years ago when the W3C decided to move from 
HTML to XHTML.

> 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.

But one of the major features we want is true compatibility with HTML
without using some pseudo-XML nonsense, but which you seem to be against
by saying the X(HT)ML is only way forward; yet still (strangly)
advocating the ability to have XHTML+XForms "work" when treated as HTML?!

> 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.

Possibly.  Are you suggesting that the XForms content could be bound to 
the input element in XBL sense (i.e. using shadow content trees, etc.) 
or that the input element in the DOM gets replaced with the equivalent 
XForms content?  If it's something completely different, please explain.

> So, since we agree with you on this point, maybe you would be 
> interested in joining XForms and contributing this feature to the 
> language.

I'm more than happy to contribute whenever I can.

> 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.

If the spec can be developed in such a way as to provide a transitional 
path like that, that would be great!

> 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.

Keeping in mind that the most prevalent of UAs to which I referred will 
absolutely, positively and without a doubt attempt to handle *whatever 
garbage you throw at it!*  That doesn't make it right to do so.

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

Received on Friday, 1 September 2006 07:57:29 UTC