The Mozilla Project has posted the first alpha of Mozilla 1.8a (and in case you missed it amidst all the WWW20004 coverage last week, they've also posted the second release candidate of Mozilla 1.7 and the first beta of Camino 0.8 which is based on Mozilla 1.7) New features in 1.8 include FTP uploads, improved junk mail filtering, and an increase in the number of cookies that Mozilla can remember. It also makes various small user interface improvements and adds support for CSS quotes.
Yesterday I wrote about what I didn't like at WWW2004 (the Semantic Web). Today I'm going to write about what I did like, because there was one technology presented that really impressed me, and that I think is going to be a key part of development in the very near future, with an exponential growth rate for the next couple of years. That technology is XForms.
Like many successful technologies before it (XML, HTML, Java, Linux), XForms doesn't really let you do anything you can't do today. It is not radically new. It does not require reorganizing the way one runs a business or develops software. Unlike the semantic web, it does not require learning completely new and unfamiliar areas of technology such as ontologies and inference systems. What XForms does do is give developers the tools to write a lot of the applications they're already writing today much more quickly, cleanly, and robustly.
I'm still learning about XForms, but what I see impresses me a lot. They are much better designed than HTML forms ever were. They have been designed with usability, accessibility, and internationalization in mind (not that any of those features ever really sell development tools, but they're nice to have when they don't cost you anything more). More importantly for XForms adoption, they lend themselves to the writing of clean, powerful code. Many things programmers really do care about like data validation are built right into XForms. Previously these have had to be hacked together with really ugly JavaScript tricks and server side frameworks. More importantly XForms are going to enable really new, server-deployed applications running inside browsers that just can't be handled in HTML. For instance, one XForm demoed at the conference essentially embedded a spreadsheet inside an HTML page. This wasn't done with ActiveX code like in IE. It was all written with declarative XForms. Up till now, browser-based applications have had fairly poor user interfaces limited functionality. XForms changes all that. You still wouldn't write Photoshop or Quake in XForms, but you certainly can write a lot of business based apps for retail, data entry, customer service, and the like; and this brings me to my next point:
I've seen many businesses standardize on IE over the last few years because they like using Microsoft's proprietary technologies for integrating data into their Intranets. It's easier to develop a lot of applications by feeding data into grid controls embedded in web pages. They get richer, more powerful user interfaces that work a lot better than anything they can achieve with standard HTML+JavaScript; and they can deploy the app over the network straight into the browser. It's a very cost effective, compelling story for a shop that's mostly all-Microsoft anyway. But with XForms the development advantage shifts. The same rich interfaces can be prepared with XForms (or XForms+CSS) even faster. The resulting applications will be much more robust, and have naturally greater separation of the data model from the user interface. (Of course, you can separate the data model from the user interface in an IE DOM solution as well, but you have to think about it and work to make it happen. With XForms, by contrast, you'd have to work pretty hard not to separate the model from the user interface.) The benefits are even larger for someone moving from traditional HTML forms+JavaScript, or PHP, or JSP. You'll still be able to use all these technologies, but you'll need to use them a lot less. Much more of the work can be offloaded into the forms themselves, and the data presented to your application in a much richer format than x-www-formurlencoded name=value pairs. XForms won't do everything, but like XML, they will do a lot more so your application can do less.
There is one big open question about XForms and that's implementation. From what I gathered at the conference there's currently exactly one high quality implementation, x-port's FormsPlayer, and it isn't open source. Pricing is of the "Call us, and we'll figure out how much we can shake out of you" variety. There's a free-beer version for developers who just want to play with this stuff, but the cost for widespread deployment is too high. There is one open source implementation of the spec, Chiba, but it isn't complete, and the people who should know at the conference didn't seem too impressed with it. Still, it's at least worth a look, and might be a good investment of time for any programmer with the time to spare and an itch to scratch.
However the holy grail for XForms support is not a browser plug-in like FormsPlayer, a standalone application like X-Smiles, or a Java/JavaScript/servlet hack like IBM's XForms compiler. Rather it's direct support for XForms built right into the browser. An organization that installed an XForms aware browser on every user's desktop could thereafter forget about most installation hassles. New custom apps could be delivered just by loading the right web page. I know we've heard this story before, but XForms looks like the technology that could finally deliver it. So, how likely is browser based support for XForms? In IE, not very likely. IE is essentially frozen, and even a few years down the line Microsoft is really focused on its own XAML, likely to the exclusion of competing technologies like XForms. The more likely host is Mozilla. Mozilla doesn't have the market share IE does, especially in business, but that's changing. Real XForms support would give businesses the same ease-of-application-development incentive to make the switch from IE to Mozilla that caused them to move from Netscape to IE several years ago. Mozilla+XForms is a potential IE killer. Unfortunately, this doesn't look likely to happen tomorrow. The vendors and developers of alternative browsers are showing surprising resistance to XForms. For instance, Opera's Ian Hickson writes:
For us (the Web browser vendors: Opera, Mozilla, and Apple), the "backwards compatible" requirement is not really negotiable, because it is quite clear that solutions that don't work in the market leader's browser won't be accepted by mainstream Web developers. I think a lot of people in the W3C world are having difficulty accepting this, especially given that Microsoft have basically said that IE has been end-of-lined (it is my understanding that IE in the next version of Windows will have no changes to its HTML/CSS/DOM/XML implementations and still no support for XHTML, and Microsoft have also stated that there will be no new separately-downloadable versions of IE available anyway, so even if they did upgrade it, it would only be used by those who upgraded their operating system).
I think what he misses is that XForms is a compelling enough story to displace IE. Market leaders can be tossed out. IE displaced Navigator, partially because Microsoft had the advantage of bundling IE with Windows, but also because they produced a superior product, at least some platforms for a few years. It's no longer true that IE is a better browser than Mozilla, Opera, Safari, and other competitors. In fact, almost everyone who's tried one or more of the alternatives agrees that Microsoft is falling farther behind every day. Microsoft's decision to halt IE development until Longhorn ships (possibly in 2006, probably later) is a disaster for them. If Mozilla implemented XForms quickly, Longhorn would enter a market in which businesses and developers were already strongly committed to XForms. XAML instead of hitting the market like Visual Basic did 15 years ago, would be more like C#, a day late and a dollar short; a nice idea, but not one that would offer developers anything they didn't already have. As Ray Kroc liked to note, and as Bill Gates undoubtedly knows, when you see a competitor drowning, shove a fire hose down their throat. IE is drowning. XForms is a nice, big firehose.
Malcolm Wallace and Colin Runciman have released version 1.12 of HaXml, a bug fix release of the XML processing library for the Haskell language. According to the web page,
HaXml is a collection of utilities for using Haskell and XML together. Its basic facilities include:
- a parser for XML,
- a separate error-correcting parser for HTML,
- an XML validator,
- pretty-printers for XML and HTML.
For processing XML documents, the following components are provided:
- Combinators is a combinator library for generic XML document processing, including transformation, editing, and generation.
- Haskell2Xml is a replacement class for Haskell's Show/Read classes: it allows you to read and write ordinary Haskell data as XML documents. The DrIFT tool (available from http://repetae.net/~john/computer/haskell/DrIFT/) can automatically derive this class for you.
- DtdToHaskell is a tool for translating any valid XML DTD into equivalent Haskell types.
- In conjunction with the Xml2Haskell class framework, this allows you to generate, edit, and transform documents as normal typed values in programs, and to read and write them as human-readable XML documents.
- Finally, Xtract is a grep-like tool for XML documents, loosely based on the XPath and XQL query languages. It can be used either from the command-line, or within your own code as part of the library.
This release changes the license to LGPL for the libraries and GPL for the tools. It also fixes bugs.