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.
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.
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.