[whatwg] Web Forms 2.0 - what does it extend , definition of same,relation to XForms, implementation reqs.

[Bill McCoy]

To be clear, I'm not hypothesizing a migration away from HTML for vanilla
"web page" content or simple web forms; I agree, it ain't gonna happen. 

But the expressed charter of WHATWG is "applications", and in the web
application domain I claim that GMail is not an extreme example of what the
future holds for "Street HTML". It's simply a fact that if you head down the
web application path with the least-common-denominator of today's popular
browsers, and want to achieve any kind of rich user experience, you end up
in JavaScript-heavy scenarios, with little to know "semantics available in
HTML". I'm speaking from experience here: touch up a photo on Yahoo!Photos
or Ofoto and you will see another instance of ridiculous JavaScript that was
nevertheless necessary to get the job done. On a more mundane note, look at
the prevalent table abuse to create precise layouts. Inferring semantics
from fixed-layout HTML is challenging, never mind JavaScript. And migration
from HTML (and from traditional fat-client apps) in the rich app space is
already happening with XUL, Flash apps and other rich-client approaches, and
XAML is looming.

I do, however, agree with your expressed advantages of WF2 over XForms
(backwards compatibility, not requiring a switch to a new paradigm). These
same advantages applied to C++ wrt C, and I happen to personally believe C++
set the software industry back half a decade vs. if (say) Objective C had
won. It is no accident that C# is not backwards compatible with C, and the
technology was available to do far better (e.g. Mesa/Cedar, which
subsequently influenced Java:
http://portal.acm.org/citation.cfm?id=806844&jmp=abstract&dl=GUIDE&dl=ACM).
And in this case I think it's clear that "Street HTML" for building rich
interactive applications is an even worse starting point than C was for
building reliable, OO software. 

The fact that Microsoft has already moved on from DHTML to XAML/Avalon
suggests that history may not repeat itself and I'd love to see us all
getting together to help create a unified standards-based approach to
building Web applications that can move the industry ahead, building on key
prior work (e.g. XHTML, SVG, XUL/XBL concepts, and, yes, XSLT and XForms)
rather than trying to reinvent the wheel. Fundamentally, I fail to see why
enterprises should be expected to keep hacking applications onto HTML forms,
with or without WF2 extensions.

--Bill McCoy
Adobe Systems Incorporated
bmccoy at adobe.com

 

 

-----Original Message-----
From: James Graham [mailto:jg307 at cam.ac.uk] 
Sent: Tuesday, January 04, 2005 7:29 AM
To: Bill McCoy
Cc: 'Henri Sivonen'; whatwg at whatwg.org
Subject: Re: [whatwg] Web Forms 2.0 - what does it extend , definition of
same,relation to XForms, implementation reqs.

Bill McCoy wrote:

>I find it odd that some WHATWG members argue that transmitting 
>arbitrary XML data over the wire to clients is a bad idea (
>http://ln.hixie.ch/?start=1064828134&count=1 )given that the solutions 
>already widely employed in Street HTML - encoding data in JavaScript 
>arrays and other tricks - are so much less "Semantic Web" friendly. To 
>pick an extreme example, Google folks admit that search-indexing a 
>Gmail screen would be extremely challenging (they themselves index the 
>raw data of course, but that's the whole point - it's much easier to 
>process structured data before it's been compiled into a presentational 
>form that is partially programmatic code). The WHATWG proposals to 
>promote scripting, rather than declarative markup, as the basis of 
>forms data binding and validation, and to dispense with an XML-based 
>data model separate from presentation, would seem likely to worsen this 
>situation by leading to more Gmail-like JavaScript-centric web
applications.
>  
>
It's not only an extreme example, it's a terrible example. Google have
repeatedly shown that they have no interest in using the semantics available
in HTML, let alone whatever additional complexity is provided by XForms -
just see any Google search results page. This is clearly not an inability to
understand the benefit to the client of good markup and so must be a
conscious decision on the part of Google. So the fact that GMail is hard to
index is just as likely evidence of malice as it is evidence that better
data/presentation separation is needed.

Even allowing that your example is misguided, I'm not sure I believe the
rest of the argument either. In order to believe that HTML should be starved
in order that XForms should flourish, you have to take the position that
there will be a migration to XForms (and XHTML) from HTML. 
In order to believe that this will offer a significant advantage to the
semantics of the web, you have to believe that authors will tend to use the
new features offered by XForms in the way that they are designed to be used.
In practice, I'm thoroughly unconvinced of the first and skeptical of the
second.

At the moment, there is simply _no_ way of migrating away from "street" 
HTML. XHTML is fundamentally incompatible with "street" HTML because the
processing requirements of HTML are satisfied by a negligible proportion of
all HTML documents. XHTML is not supported in any meaningful way by the
world's most commonly used web browser. There are few existing CMS solutions
that are able to produce XHTML reliably, let alone arbitrary XML, and few
users who understand the technical requirements of XML. The combination of
all these factors makes it very hard to migrate away from HTML to anything
that is not explicitly compatible with it.

Even if people could migrate away from HTML, it is doubtful that they would
suddenly learn the benefits of sending semantic documents over the wire, nor
the ability to understand complex specifications well enough that they would
produce high-quality documents. I would expect that in XForms, as in HTML,
if there is a way to hack a solution that looks/works as expected then
authors will use that at least as often as they use the neat solution
provided by the language.

The major advantages of the WHATWG specs over XHTML/XForms are
1) Backward compatibility. They can be used in situations where there is
existing content that must be integrated and a limited migration budget
(i.e. most real world situations)
2) Limited additional complexity. Because Web Forms 2 is close to HTML 4
and, in particular, because it does not switch to a model in which
everything is done declaratively, it is familiar to existing authors and, as
a consequence, is more likely to be understood, adopted, and used in a way
compatible with the specification.