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

[Bill McCoy]

James,

I basically agree with you. There are multiple paths to building apps:
"Street HTML" (as Opera calls it) and (as you call it) "XML Soup". Modern
browsers to varying degrees support both the HTML-centric and XML-centric
approaches, just as Visual Studio support multiple languages. So I believe
it's valid to discuss (in the topic of extending modern browsers) how much
to push the one side vs. the other. For example the side discussion that
this thread somehow triggered about client-side XSLT goodness is clearly
relevant to the XML-centric application approach, and it is or soon will be
supported in 3 of the top 4 browsers. But yes, ultimately the market will
decide how applications will be built and deployed: developers will vote
with their feet. 

I do disagree with the assertion that I was taking the technology point of
view on the C++ vs. C point and its application to the HTML vs. XML
application discussion. Yes it's futile to second-guess history, and I agree
the potential merits from the point of view of users (developers) is all
that matters. But just because developers adopted C++ doesn't prove it
delivered the best value proposition (in isolation) of all potential
solutions. The decisions of people at Microsoft and others to support and
market C++ were instrumental in creating the total value proposition that
led to C++ winning. Just as the decisions of people at Mozilla, Opera, and
Apple (and of course Microsoft still) will be critical parts of creating the
total value proposition around both HTML and XML-centric applications. I am
merely pushing for you guys to make decisions in the interests of those
users as you balance your efforts between HTML- and XML-centric
capabilities, I don't give a hoot about technical merits in isolation.

I also agree "worse is better"... But this principle is always "... to a
point". A toolbox doesn't just contain a hammer, even though a hammer is a
"worse is better" solution to a lot of problems. We've all built a lot of
great server-based HTML apps in recent years, but precious few of them
deliver the user experience quality of a basic VB desktop app. Demands for
usability are rising but the complexity of HTML app development scales
nonlinearly as even semi-usable experiences are sought. Amazon and Expedia
are not bad but look what they expend in dev costs. Gmail is pretty rich but
look at Google's resources. It has to be possible to build rich apps,
simply. As someone else said in another thread somewhere "it's 2005 and
we're still talking about rollovers". I happen to believe that "Street HTML"
just won't cut it for building rich interactive clients that are highly
usable (by the ultimately users, end users not developers), and that the
best "worse is better" foundation lies in the XML technologies that have
been established in recent years (XHTML among them), and that promoting
these technologies would be better for the open/web community than letting
proprietary tools win. Clearly a number of people on this list do not agree.
We will see.

--Bill

Bill McCoy
Adobe Systems Incorporated
bmccoy at adobe.com

-----Original Message-----
From: James Graham [mailto:jg307 at cam.ac.uk] 
Sent: Wednesday, January 05, 2005 10:03 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:

>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.
>  
>
This seems to be the crux of your argument. You're arguing from the point of
view of a "technologist" i.e. someone who judges the merits of a technology
for its own sake rather than the merits from the point of view of a
potential user of that technology. But that's a rather specious position to
take; the value of a technology is only in its usefulness to people. I don't
see how one can say "if only people had used some other language than C++
we'd be five years further on" - clearly users (i.e. application developers
or their employers) made a descision at the time that the features of C++
best fitted their needs and so it was used. If C++ hadn't been invented,
some other technology would have come along with similar appealing qualities
(C compatibility presumably being an appealing quality), and people would
have used that instead. Or they would just have kept on using C. So it's
impossible to say "oh if only such and such had been different things would
be so much better" because it ignores all the context and reasons for
whatever it was happening i.

To get back to a more definite point; the fact that we have a bunch of
javascript heavy HTML-based web-applications at the moment reflects the fact
that, at the moment, javascript-heavy HTML based solutions work for the
majority of potential customers and so are an attractive choice for people
implementiung web applications. It's not a poor basis so much as it is one
of very few viable bases (Flash being perhaps the only other). 
If that's a less than ideal choice technologically then people need to work
at getting improved choices in the hands of customers. XML-soup (i.e.
XForms, XHTML, SVG, sXBL, RDF/XML and whatever other standardised XML
langauges are needed to achieve the desired feature set) and "HTML5" 
( Web Forms 2 + Web Apps) are /complementary/ approaches to improving the
situation for web applications. XML-Soup is the "technologists" 
approach - it strives to be elegant and solve all the problems with the
existing systems. HTML5 is the "worse is better" approach; it strives to
achieve what is possible without dispensing with some measure of backwards
compatibility. Which is the "best" approach is not something that can be
derived apriori - it is ultimatley the market of web application developers
who will have to decide which provides the functionality they need. Nor is
it harmful to have two standards-based efforts; better to have two standards
based efforts with some degree of overlap than leave a gap which is
ultimatley filled by some proprietry solution. 

>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.
>
I don't see anyone being forced into using Web Forms 2. Neither, for that
matter do I expect that they will be forced to use XML-Soup or XAML or any
other paticular solution. I expect that they will pick the solution that
they believe will best fit their needs. In this, "HTML5" 
and XML-Soup are complementary since they have different strengths and are
sutiable in different circumstances. I don't see why people advocating the
XML approach see the development of alternatives, to meet different needs,
as so harmful even when they claim to see the advantages that the
alternative solutions offer. Similarly XAML will presumably have different
strengths (tight integration into Visual
Studio) and different weaknesses (Windows Longhorn-only). If the goal is to
compete with XAML, I would suggest that you look at the strengths of XAML
and see how well XML-Soup holds up. I would consider the ability to create
simple form applications in a 'point and click with as much magic code
generation as possible' way to be a much stronger requirement than the
requirement that only a single standardised langauge exist to acomplish the
full range of possible web-application tasks.

So to answer the original questions (except the bit about implementation
requirements):
 > what does it extend:

HTML4. Part of this extension is by standardised features that are actually
implemented in "streetHTML" browsers, but HTML4 itself is the basis.

 >definition of same

http://www.w3.org/TR/REC-html40/

 > relation to XForms

A different technology with different priorities that will lend itself to
different groups of people doing different things, even if what is being
done is still called "Web Applications" (in the same way that Lisp and Perl
can both be used to create "Applications")