XForms Everywhere

On a daily basis, I happily use a subset of XML which is quite simple, notwithstanding some little issues with namespaces and qualified names, which I can live with. This includes using XML for XHTML, XForms, XSLT, XPL, RSS, DocBook, custom document formats, and whatnots.

But while writing a short introduction to XML in the upcoming book about Web 2.0 we are writing with Alex Vernet, Eric van der Vlist, Danny Ayers and Joe Fawcett, it struck me again how complex XML actually is. You go back to the XML specification, and you realize that XML covers such monstrosities as (gasp) DTDs, entities and (an arguable gasp here) processing instructions. These features alone seem to eat up more than half of the XML specification (I haven’t counted the lines). Together they build a tricky mess of scary syntax, difficult concepts, processing hell, and the one question that pops up when you are done skimming through the spec again is: why?

We actually know why: XML has history. For example, it made sense to migrate SGML DTDs to XML back in 1996-1998 when there was nothing else around. Nowadays, for all its shortcomings, people tend to use XML Schema, or the more user-friendly Relax NG and Schematron. There is nothing that DTD offers that these new validation languages don’t.

The same goes for entities. They are today used for various purposes, including specifying characters by name, and inclusions. The former use certainly needs a new solution (some have already been proposed), and the latter is solved with the cleaner approach of XInclude.

Finally, processing instructions are a contentious subject. I for one can live with them, but I wouldn’t complain if they disappeared in an upcoming revision of XML.

What I have realized is that these issues are no revelation in 2006. I propose below links to several related articles and proposals dating back to 2002:

• Tim Bray’s 2002 XML-SW proposal.

• Kendall Grant Clark’s 2002 XML 2.0 — Can We Get There From Here? article.

• Norm Walsh’s 2004 XML 2.0 article, which also points to more resources.

The list of issues raised in those articles and proposals goes further than the two or three issues I tackle above, but DTDs and entities appear to be recurrent.

So what do you do until a hypothetical XML 2.0 sees the light of day? It’s fairly simple: just make sure you don’t unnecessarily carry the burden of legacy and compatibility features such as DTDs and entities, and stick with the features of XML that are simpler to understand.

NOTE: There is currently no such thing as “XML 2.0″. The term is just a placeholder for a hypothetical future version of XML that would improve and simplify XML 1.0 and XML 1.1.

Nokia has just announced that it has open sourced its mobile browser. According to Nokia, “The new Web browser for S60 is based on the WebCore and JavaScriptCore components of Apple’s Safari Web Kit that Apple uses in its Safari browser.”

This is great news for mobile applications, since this is the second mobile browser which supports the technologies required for Ajax, along with the Opera browser.

Many forms have a “Save” button. From a usability perspective, it makes sense to disable that button when saving is not allowed. There are two obvious scenarios where this arises: when the form has been modified but contains invalid data, and when the user has not modified any data at all. We show here how to handle the latter case.

What we want to do is enable the “Save” button only when the data in the form is “dirty”, in other words when it has changed. For this purpose, we use a special control XForms instance containing a <dirty> element which will contain the string true when the data is dirty, and a <save-trigger element with an XForms binding to tell the “Save” button to be disabled when the data is dirty:

<xforms:instance id="control-instance">
    <control xmlns="">
        <dirty>false</dirty>
        <save-trigger/>
    </control>
</xforms:instance>
<xforms:bind nodeset="instance('control-instance')/save-trigger" readonly="not(../dirty = 'true')"/>

The “Save” button is then simply bound to the <save-trigger> element, and will automatically follow the readonly property as it changes on the <save-trigger> element:

<xforms:trigger ref="instance('control-instance')/save-trigger">
    <xforms:label>Save</xforms:label>
    <xforms:send ev:event="DOMActivate" submission="save-submission"/>
</xforms:trigger>

XForms provides you with a very simple way of detecting value changes in a form control: the xforms-value-changed event. Now the nice thing with XML events is that you can register event handlers at any point in an XML hierachy. This means that you can put a single handler detecting any value change in your entire form:

<xforms:group>
  <xforms:setvalue ev:event="xforms-value-changed" ref="instance('control-instance')/dirty">true</xforms:setvalue>
  <-- Other form controls are nested here -->
</xforms:group>

And that’s it: the “Save” button starts as disabled, and switches automatically to enabled when any value in the form changes.

To wrap this up, you can revert the button to being disabled when saving succeeds:

<xforms:submission id="save-submission" method="post" replace="none" action="/save-document">
    <xforms:setvalue ev:event="xforms-submit-done" ref="instance('control-instance')/dirty">false</xforms:setvalue>
</xforms:submission>

Finally, note that you can also detect XML instance insertions and deletions if you use <xforms:insert> and <xforms:delete>. This time, you add two event listeners in your XForms model:

<xforms:model id="main-model" schema="oxf:/examples/forms/detail/form-schema.xsd">
    <xforms:setvalue ev:event="xforms-insert" ref="instance('control-instance')/dirty">true</xforms:setvalue>
    <xforms:setvalue ev:event="xforms-delete" ref="instance('control-instance')/dirty">true</xforms:setvalue>
</xforms:model>

A perfect version of this would not only detect controls value changes, but actually compare all the current values of the form with the initial values of the form (or the values just after saving). However, for most practical purposes, the solution presented here is just good enough. In fact, it may even be considered more intuitive to the user, who otherwise may wonder why his “Save” button is disabled when he in fact has interacted with the form.

Thursday and Friday were the last days at XTech 2006. I have to admit that I missed most of the Thursday morning talks in order to rehearse my own, so I don’t have much to report except Mark’s Building Rich, Encapsulated Widgets Using XBL, XForms and SVG which I mentioned earlier. In the afternoon I attended Ryan King’s The Intelligent Design of Microformats, Mark Birbek’s RDFA: The Easy Way to Publish Your Metadata, and Dean Jackson’s Standardising Web Applications: Rich Web Clients at W3C.

Then came my talk, XForms: an alternative to Ajax?, which I think had good success, with a decent number of questions and comments, as well as a few offline discussions afterwards. The talk / paper has been qualified online eye-opening and readable and very good (let us know if you find other references, positive or negative).

On Friday, I attended the talks on mobile web, including Opera’s Michael Smith’s Bringing Web 2.0 to Mobile Devices, Opera’s Håkon Lie’s Mobile Web Applications, and Nokia’s Andrei Popescu’s Mini Map - A web page visualization method for mobile phones. The idea of using standard web technologies to deliver applicatons to mobile devices is clearly an attractive one, and it is worth looking at W3C’s Mobile Initiative and Mobile Web Best Practices 1.0 documents for inspiration.

I then went to see Amazon’s Jeff Barr’s talk on Amazon Web Services, which turned out to be a mistake since there was about 100% repeat with his closing keynote on the Amazon Mechanical Turk. The Amazon Mechanical Turk is clearly an amazing idea, but I knew about it already and did not learn that much during the closing keynote. I believe the potential of this service has yet to be unleashed and I think we are going to see some quite amazing uses of it in the coming years.

XTech closed with Brendan Eich’s JavaScript 2 and the Future of the Web. Brendan did a great job describing the new features of JavaScript 2 as well as addressing common criticism towards that evolution. The reasoning goes as follows: the future of the web is going to be XBL and JavaScript, so we better make JavaScript darn good. The idea that XBL and JavaScript will allow implementing XForms and newer markup languages without upgrading browsers is very appealing, although it assumes that browsers will implement XBL and XBL 2: currently the only browser working on this is Firefox, and as always, Internet Explorer may be the thorn in the side of these brilliants efforts. Whatever the outcome, XBL appears to be an excellent solution to extend XForms, on the client or on the server.

All in all, this year’s XTech conference was good, with such emerging themes as Ajax, declarative markup, XBL, and services, all topics relating directly to XForms and Web 2.0. The discussions around the mobile web were interesting as well. The conference was not perfect, in particular I wish the audience had been more varied. The next edition will be in Paris, and I am already looking forward to it!

The proceedings for the XTech conference are now online on the XTech web site. Here is the link to our paper: XForms: an Alternative to Ajax?

Many of the talks I have attended do not have papers online yet, but following-up on the subject of the use of XBL with XForms I talked about earlier, here is a link to an XForms-related talk which I was unfortunately unable to attend: Building Rich, Encapsulated Widgets Using XBL, XForms and SVG.

Yesterday was the second day at XTech 2006, and the first conference day. We had a very entertaining albeit a bit provoking keynote by Paul Graham about what it would take to reproduce Silicon Valley somewhere else.

I attended talks about real-life Ruby on Rails (BBC), XBL 2 (Mozilla), and Jabber. I also chaired two sessions, one about the Google Data API, and one about algorithms to implement numerical constraints in XML Schema, a very technical talk but quite well presented by Henry Thompson.

XBL 2 appears to be a perfect technology to use with XForms, and people like Mark Birbeck in fact have already implemented XBL in conjunction with XForms. The promise: using XBL as way of implementing new XForms components, whether written in markup and Javascript, or whether written with XForms themselves. In OPS, we could implement XLB 2 server-side and use it to provide an easy way to both encapsulate existing Ajax widgets as well as allowing users to define their own compound XForms components.

The Google Data API talk mainly revolved around Google Calendar. The cool thing is that this API is based on the Atom format, and supports updates. The demos showed how you can use C# to access that API. I almost fell off my chair while thinking that this should be much easier with XForms, as you can access XML services directly! For now, this is a new opportunity for a cool mashup demo.

The day ended with lots of discussions about XForms with the subset of the XForms working group present at the conference, and sightseeing from the roof of our working group chair’s house.

Yesterday was my first day at XTech 2006 in Amsterdam - the pre-conference day, with tutorials and a special “Ajax Day” track. I was unable to attend all the sessions and one presenter did not show up, but I did attend the talks on Dojo, OpenLaszlo, Flex, and Backbase.

Most interesting was the presentation of the Yahoo! User Interface library (of which we currently use the slider component to implement xforms:range). It appears that there is much more from it we could use in Orbeon PresentationServer, from basic facilities to event handling (even as the page loads), to animations to other widgets like the tree widget, and drag & drop.

The day ended with a series of 8 or 9 lightning Ajax demos, where we showed the OPS Ajax-based XForms engine - it was quite a challenge to do this in 5 minutes, but I got my last screen showing up as the clock marked 0:00!

Now for the philosophical part. As interesting all the presented technologies and frameworks are, most of them expose Javascript fairly heavily to the page author. This is true for the lower-level Dojo and YUI, of course, which doesn’t bother me the least as I see those frameworks as the “deployment” technology for XForms. But this is also the case for the higher-level OpenLaszlo and Flex - at least, they assume that you need Javascript to do something really useful, meaning by that a user interface that actually reacts to user interaction.

Now Javascript does come in handy at some point. However, with XForms, that point seems to be that much further removed, and this is simply due to XForms Events and actions and the underlying XML Events framework: a lot of thought has gone in those to define a small set of useful events and actions that greatly reduces the need for Javascript. While XForms is not quite unique in that respect (as I discovered with the Backbase presentation), it has that edge over most competing technologies. Now, add to that the fact that XForms is a standard, and of course you get a real winner.

XTech 2006 is going on right now in Amsterdam. As mentioned earlier, Erik will be giving a presentation on Thursday at 4:45pm entitled XForms: an alternative to Ajax?

This has been an amazing year for Ajax, and XForms has picked quite a bit of steam during this year too. On one hand, Ajax offers greatly improved UI capabilities compared to vanilla HTML and it makes a great deployment platform. On the other hand, XForms provides semantics, simplicity, and robustness. With XForms deployed on top of Ajax, we believe that those two technologies make a very complementary pair and provide a powerful, simple, and robust solution for forms and more.

We’ll soon post here the slides to Erik’s presentation. In the meantime you can check the slides of Steven Pemberton’s presentation about XHTML2 & XForms.

You are proud of your well tested web application, and it runs just fine on your own development machine. However, when you deploy it on a Windows XP staging server and perform load testing, you start getting, from time to time, this error message: “Server access Error: Address already in use”. This does not happen in the browser, but on the server. Yes, your web application connects to a server, say making REST API call through HTTP. So that must be the source of the problem: sometimes, the connection from your application to the server just fails.

Not all the connections fail, say only 1 out of 10 fails. And this only starts after the server has about 3000 requests. Yes, you can’t see a single error for the first 3000 requests. This is when you start thinking about cosmic rays as a possible explanation.

Cosmic rays are not the answer, the way TCP/IP is implemented in Windows is. When an application connects to an HTTP server, a connection is made to port 80 on the server, but because this is TCP/IP, a port is also open on the machine that runs the application. That port number is assigned by the operating system and is by default in the 1024-5000 range on Windows. With TCP/IP, after you close a connection, the local port won’t be reused for a few minutes.

If your application is under load, you can easily run into the situation where all the ports between 1024 and 5000 have been used and closed already, which leaves no port available to establish new connections. Hence the errors.

One simple solution is to tweak Windows and make this range larger. Changing it to 5000-65534 is very likely to take care of the issue. You can do this by changing the MaxUserPort parameter in the Windows registry. This also gives an additional reason to do connection pooling (and some will say to deploy your web application on a server that runs UNIX instead of Windows).