[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")

Received on Wednesday, 5 January 2005 10:03:00 UTC