Saturday, June 25, 2005

Ajax-Enabled XForms

Ajax-Enabled XForms

There does not appear to be an end to the Ajax craze, witness the amount of activity reported by Of course, Ajax does not solve all the problems of the world, and it comes with a series of new problems of its own.

For those who missed the boat, Ajax is a way of letting lightweight scripting code in a web browser communicate with your web server by exchanging XML documents. The net result is that you can create web applications that are more "rich" and responsive than traditional web applications, yet do not require plugins, Java, Flash, or even insane amounts of Javascript on the client. Google Maps is one of the most popular examples of this technology.

Yet implementing Ajax is not trivial. There are some Ajax libraries out there, but they usually concentrate on offering platform-independent support for interacting between client and server, and a few other goodies. They no not address the questions of:

  • How you create on the client the XML data to send to the server
  • What you do on the client with the XML data returned by the server
  • How the server processes the XML data it receives and how it builds a response for the client

In short: Ajax remains a very low-level tool.

But now look at what people use Ajax for:

  • Improved HTML widgets (such as dynamic drop-down lists)
  • Displaying data dynamically provided by the server as the user interacts with the application
  • Modifying the appearance of the current page dynamically

If you are in the know, you just want to say: "Have you heard of XForms?" Because yes, those are some things that XForms allows you to do:

  • Use several widgets much improved over their HTML versions, including novelties such as sliders and repeated sections
  • Submit XML data and receiving new XML data back, thanks to the replace="instance" submission
  • Dynamically modify the appearance of a page by hiding and showing parts of it, by repeating sections of the form, or by updating selection lists

There is of course a little problem, which is that XForms is currently not widely availble in web browsers. You are forced, at the moment, to use plugins or incomplete server-side implementations. But what if you had... an Ajax-based XForms implementation?

The answer to that "what if" scenario is quite exciting: much of the need for coding low-level Ajax is removed with an Ajax-based XForms implementation (or a full client-side implementation, for that matter). Of course XForms may not do everything you may want to do with Ajax, but it does a good deal already. With extensions, which are easy to provide if like Orbeon PresentationServer (OPS) you have a server-side XForms implementation, you can build more advanced functionality on top of XForms.

So we haven't been sleeping at Orbeon: our next generation server-side XForms engine, part of OPS, is Ajax-enabled, not only because it's a cool technology, but because it makes our XForms implementation just better and because it opens doors so far closed to everyone but the hardcore Ajax developer.

We hope to have a beta of the new XForms engine very soon, likely in early July. But if you are impatient, you can always download the latest unstable builds of OPS or get the source from CVS, and you can follow our latest developments there. Look in particular at the new Calculator and XForms Controls, as well as the Translate This and the updated sandbox examples.

NOTE: We discuss the whys and the therefores of Ajax-enabled XForms in our recent XTech paper .

Wednesday, June 22, 2005

Choosing The Right Database

In the early life of a project, there is always this time where the question of the day becomes: And now, what database should we use? (Of course, this is assuming that there is a choice possible.) This is at time where our decision is often unfortunately influenced by preconceived ideas. Our preference for databases we have already used in the past, our opinion of open source software, or our experience with SQL and XML technologies are all biases that will overly contribute to our final decision.

In an effort to get past personal biases, let's look at databases from a different perspective, and focus for a moment on these two fundamental properties of every database:

  • What is the license? (Is it a commercial or an open source database?)
  • What is data format? (Is this a relational or XML database?)

Now that we have those properties in mind, let's look at them in terms of benefits and drawbacks. Specifically, let's see how they impact cost and risk:

  • Commercial vs. open source: Obviously commercial software can't beat open source on the licensing cost. However commercial software tends to have longer track records, and better scalability than open source software, which reduces risk.
  • Relational vs. XML: Relational databases are deployed everywhere: the relational technology is mature. On the other hand XML databases are widely deployed in some verticals but lag in maturity compared to relational databases. Will the database handle the load? Will the project or company behind this database still be there 5 years from now? Those are all questions that don't find a clear answer for most XML databases, which is a factor of increased risk. On the other hand, storing data as XML documents accelerates development and makes applications more flexible.

The trade-offs are typical: with increased risk come greater rewards (and lower cost). Think about what differentiates you from the competition:

  • Is licensing cost per CPU is an issue? Are you going to deploy your solution on a large number of servers? If it is think about open source. Otherwise a commercial database might be the safest option for you.
  • Do you need a great amount of flexibility? Will the format of data your application will work on change frequently? If this is the case, an XML database might be the right choice for you. Otherwise a relational database should do just fine and you will be able to choose amongst a number of industry proven databases which will reduce risk.

Now the choice is yours!

Monday, June 6, 2005

Back from XTech 2005

Tech 2005

It is time for a (quite late) review of XTech 2005 in Amsterdam! The good news is that I can now simply point to other reviews of the conference, in particular Micah Dubinko's extensive coverage.

XTech was a wonderful opportunity to meet the XML crowd, from many of the big XML heads, to OPS users, to people just in search of what XML can do for them.

My main interests were XForms and XML pipelines, and from that respect the conference was quite fruitful. There was quite a lot of interest around XForms, including talks about the OpenOffice implementation, using XForms for validation purposes, integrating XForms and XSL-FO, and of course our own talk, Are Server-Side XForms Engines the Future of XForms?.

In the XML pipelines (A/K/A XML processing model) area I attended a product presentation of Henry Thompson's MT Pipeline, as well as Jeni Tennison's excellent introduction to XML pipelining technologies. Let's hope her call for a standardization effort will be heard!

There was more, of course, including a pretty heated debate between XHTML 2.0 and the WHATWG "HTML 5" efforts. My own inclination is that I like the very clean approach taken by XHTML 2.0 over the "big bag of stuff" approach of WHATWG.

As others have already noted, the overall quality of the sessions was excellent and it was at time difficult to choose between sessions. Edd Dumbill should be acknowledged for an excellent conference!

All XTech papers and slides are available here:, including our XForms talk's slides and paper.

Update: The IDEAlliance web site still doesn't show the updated version of the paper as of October 2005, but here is a link to it on the Orbeon web site.