Re: IBM Position Statement on XForms and Web Forms 2.0

On Aug 31, 2006, at 17:45, Mark Birbeck wrote:

> But I do feel that your comment reflects an old-fashioned view of
> internet technologies.

I think a big part of the rift between the XForms/SVG-as-app-platform  
camp and the WHAT WG camp is that the former considers Web browsers  
old-fashioned. (I don't consider browsers old-fashioned.)

> With the installation of
> XForms functionality *once* you get to build a large part of your
> desktop application using declarative mark-up.

I think declarativeness is overrated when it comes to apps. What's  
*so* bad about an imperative scripting language, really? (Lisp may be  
theoretically nice, but people still write desktop apps in imperative  
languages. And yes, I have written Scheme programs myself.)

The *one* justification for declarativeness over JavaScript that I  
have heard from an XForms implementor was that you can statically  
analyze which form fields affect other form fields (before the user  
actually triggers any changes) so that software can describe the  
relationships in audio when the user is driving a car without the  
form author providing an explicit audio UI. I may be missing the  
point, but I wouldn't want to fill in tax forms when I'm driving. :-)

BTW, the idea of writing a lot of verbose XML instead of writing a  
few lines in an imperative programming language makes me have  
enterprisey flashbacks of J2EE stuff that saves developers the  
trouble of writing a few lines of Java by making them write a huge  
lump of XML configuration files.

> And the different
> XForms implementations reflect this--you can go from a server-hosted,
> zero-install solution like Orbeon or Chiba

As Lachlan pointed out, the Orbeon style is exactly the  
implementation style that is presented in the WF2 spec.

>> XForms is also requried to be used within an XML document served  
>> with an
>> XML MIME type, such as application/xhtml+xml...
>
> That's not true. XForms not only does *not* mandate a MIME type, but
> it doesn't even mandate a specific host language!

XForms says it is an XML language and XML requires an XML MIME type.  
Even if that point of view may feel uncomfortable, the point of view  
that real-world browser engines (Trident, Gecko, KHTML/WebKit and  
Presto) don't parse text/html as XML is an observable fact, so for  
all practical processing purposes text/html is tag soup--not XML.

> (in the same way as Acrobat, for example)

On the point of Acrobat and MIME types, the PNG spec (to pick an  
example) doesn't need to say that it is inappropriate to send PDFs  
labeled as image/png. (Likewise, looking for normative references on  
what text/html *isn't* is the wrong approach.)

> I don't really understand this, although I'm trying. Just so that
> people aren't getting the wrong impression here, an XML document does
> not cease to be XML just because it is delivered with the wrong MIME
> type

For practical purposes it does, if it isn't parsing using a  
conforming XML processor in real-world implementations.

> is that MVC architecture is a 'good thing'; why in the world
> would people using such concepts want to go backwards to HTML forms
> when they've spent years trying to escape their limitations?

You can have MVC in JavaScript. In fact, I have implemented one such  
app (but can't demo it due to its proprietary behind-a-firewall  
nature). It had an XHR-loaded/saved XML document as the M, an HTML 
+CSS document as the V and a JavaScript program as the C.

>  * so to know how many pages are delivered as XHTML you'd
>    need to know what systems are doing the delivering--the
>    MIME type tells you nothing.

It tells you what code path real browser engines use for processing  
the document.

> My guess is that a lot of systems are generating pages on the fly on
> the server, and are using XML-related tools to do so, and when the
> page is ready, the server tacks the text/html MIME type on at the last
> minute. But of course I can't prove that, no more than you can prove
> your view that when people use the text/html MIME type, they are
> delivering 'real' text/html pages.

PHP-based systems, JSP-based systems, ASP-based systems, etc., etc.  
all use string-based tag soup templating methods. It is notoriously  
difficult to bullet-proof them to emit real XML.

It seems to me that systems based on DOM/XOM, SAX or XSLT are  
relatively rare. And if you really have a truly XML-based system, it  
can emit SAX events. Once you have SAX events for an XHTML 1.0  
document, you can serialize as HTML 4.01 trivially. And the  
serializer is not a particular burden, because you need a special- 
purpose serializer for the infamous Appendix C as well (an  
inconvenient detail that is often conveniently ignored).

> Our XForms/Ajax implementation sits on top of any Ajax library--so
> will work with YUI, Scriptaculous, etc. So if Amazon and GMail can use
> an Ajax library, then they can use XForms. It's no big deal.

What happened to end-to-end declarativeness?

> (Just as an aside, the kind of implementation you mentioned before,
> where scripts are used to provide support for WF 2.0 in browsers that
> don't provide such support natively is not beyond the abilities of
> XForms developers! It's really not that difficult!)

Except WF 2.0+JS-based apps don't pretend to be fully declarative.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 1 September 2006 13:16:09 UTC