- From: James Graham <jg307@cam.ac.uk>
- Date: Wed, 05 Jan 2005 18:03:00 +0000
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