On Adobe and XForms via Declarative Programming, Wizards and Aspects

My previous blog about building RESTful applications with XForms (A del.icio.us Link Manager Written in XForms) has prompted a reply from Bill McCoy at Adobe. Bill is responsible for platform product management, which includes the desktop and mobile versions of Adobe Reader, and the associated PDF technologies. By all accounts he has good reason to be interested in the 'next generation' of internet applications.

The main point of his blog is that the declarative approach to building internet applications that I have been championing is:

still a bit of a Holy Grail: a rich application may be able to be built script-free but while I'm a bit astonished at what Mark has shown can be accomplished within XForms, at some point the complexity of the XML markup arguably exceeds what a script-based approach would have produced.

Flattered as I am that Bill is impressed--and the good news is that we have plenty more applications to be released that are even better than the ones currently available--I have to disagree with this view that the complexity of XForms applications increases until "at some point", scripting works out better. I'll look at this, as well as the more substantial point of Bill's blog, that the declarative approach itself is a problem, and actually not as useful to programmers as better code-generation tools.

Complexity

The particular example of "complexity of the XML markup" to which Bill is referring is in the RSS Reader application that I built using XForms. (This application is provided automatically when you install formsPlayer, but the source is available as a text file.) The main thing that he is honing in on to illustrate this 'complexity' is that in order to create a looping construct I was forced to use a workaround. Since XForms does not yet support loops, I used an XForms action that deletes a node, and then used the notification event that deleting a node generates, to delete the next node. In effect we get a while loop that lasts as long as there are any more nodes to delete--but as Bill rightly points out, it's rather an odd way to get a loop!

It should be said firstly that the main reason for doing this is to convert the data read from the many different types of RSS feed that are available into a common format for storage, in this case XHTML 2. If I had just stored the feeds 'as is' then no loop would be necessary, but one of the things that I wanted to illustrate with the application was how XHTML 2 will increasingly become the 'universal document'.

And it should also be added that I was trying to show how the whole thing could be done using XForms 'out of the box', with no proprietary extensions. As more and more XForms processors emerge and head towards the full implementation of XForms, then my RSS Reader should work with them, regardless of whether the target processor is geared up for speech, SVG, XHTML and so on.

Those Slow Standards-bodies

But more importantly, if this is the only criticism we have of XForms' complexity, then I'm pretty pleased. Let's be honest, adding a looping feature to XForms (or XML Events) would take no time at all, and once it has been added I could then remove the workaround.

(And as it happens, David Landwehr from Novell has already proposed a set of extensions to XForms, such as if and while, and he has even implemented them in his processor. Bill's criticism is therefore largely about the lumbering process of creating and updating standards, and not the architecture of the language. That is still a legitimate criticism, and one with which I concur strongly.)

Streamlined Scripting?

But putting aside the complexity of my workaround, I seriously doubt Bill's claim that a script version of an RSS reader would be less complex than the XForms I have produced. Looking at the scripts for internet applications such as Google Maps, GMail, Microsoft's Virtual Earth, and so on, they are incredibly complex, and require pretty large teams to both build and maintain. And the reality is that so far, RSS readers aren't written using script anyway¹--they're built with C++, Java or VB. Which therefore makes it all the more impressive that an XForms RSS Reader can go toe-to-toe with applications built with such serious programming languages.

Wizards

Bill's more substantial point is that maybe what the world needs is not some new declarative programming paradigm at all, but better tools for generating procedural code. He gives the example of Ruby on Rails, which is an environment that automatically generates the large numbers of files needed to build typical web applications that are based around a database. The framework makes it easy to build a RESTful application which could add and delete customers, for example, handling the automatic generation of a UI, the generation of SQL queries to manipulate the data, and so on.

But a sub-text of everything I have been tring to illustrate in my blogs and XForms-based applications is that the wizard part is easy if the underlying architecture is right. That's why I frequently try to show that you can build powerful applications using simple text editors, since after that it's a no-brainer to build a tool that generates the right XML.

And one of the main reasons I have taken this approach is that in nearly all cases I find the 'wizard approach' is great to get you started, but then very quickly gets complex again. Anyone who uses Microsoft's Visual Studio, for example, will know that getting a C++ application up and running quickly, with support for multiple windows, toolbars, printing and file saving, is a snip. But then when you want to modify that code and move away from the wizard, you are very soon into normal C++ territory.

That's fine if you are a C++ programmer, and your employer has time to wait and budget to use up. But if all you wanted to do was produce, I don't know, let's say...an RSS reader as a side-bar in Internet Explorer, then it's a lot of work for what should really be a simple application².

In many ways Ruby on Rails follows the same lines as the Visual Studio wizards; you can generate a large number of files for one of the standard application types, which gets you off your starting-block pretty quick. And if you enhance that application along established lines, your productivity can remain quite high. But stray too far, and soon you will again be on your own, in the world of templates and the rather obtuse Ruby programming language³.

So no matter how good a wizard might be, the real question is how productive will you be in the underlying language, once you have moved beyond the capabilities of the wizard.

But even this is not the whole story. Although I feel that XForms can hold its own as a language that can be used in a very wide range of applications (with obvious room for improvement), the key to my approach to internet applications is in the way in which code can be re-used.

Re-use

What I have been championing for the last few years is not XForms as the solution to everything, but XForms as a component of a much wider solution. This point is important, since focusing solely on my support for XForms has led Bill (and others⁴) to suggest that I am over-egging the pudding:

It seems to me that if declarative model-based approaches to application construction are going to take off, advocates need to change the rules, and stop trying to oversell programmers and scripters on non-programmatic approaches.

I have never claimed that XForms is a "non-programmatic approach"--far from it. What I have said though, is that just as more programmers can use C than assembler, and more programmers can use Visual Basic than Java, so I believe that a programming model based around events, declarative mark-up, a spreadsheet-like dependency engine, automatic reflection of model state to the UI, automatic validation using standards, easy encapsulation of data submission, and so on, is easier than scripting, AJAX, C++, VB, Java, and yes, even Ruby on Rails. And that has to lower the bar.

And the most important features of the 'approach' that I am trying to "oversell programmers and scripters on", concern (a) the dynamic extension of objects at run-time, and (b) a declarative virtual machine. I'll be writing more on this shortly, and it will also be the subject of my comments on a round-table at SD Best Practices (XForms, Web Forms, or What? The Next Generation of Rich User Interfaces, with Elliotte Rusty Harold, Stefano Mazzocchi, and Luis Derechin), but for now I'll just touch on a couple of things:

• the dynamic extension of objects builds on XBL to allow objects to be 'decorated' at run-time to provide functionality that simply cannot be achieved with traditional class inheritance. The approach I'm taking is not unlike aspect programming but it happens at run-time, and of couse unlike the usual way of doing aspects, the definition of the cross-cutting concerns is itself declarative;


• the declarative virtual machine is something that I have outlined in the past, but it allows complex functionality to be built up from other declarative components in a simple modular way, such that not only is development and testing quicker, but even specifying standards is faster. It's more akin to an XML pattern language.

I'm hoping to look at these issues a little more on this blog, in the lead up to the SD Best Practices conference, but to re-cap this discussion; Bill suggests that my approach to XForms evangelising is to make wild claims for declarative programming, before suggesting that what we really need are better tools. My response is that any bold claims I do make are for a whole new approach to developing applications, of which XForms is only a part...albeit a crucial one.

Applications that Build Applications

However, none of what I have said above would cause me to disagree with Bill's closing comments:

Instead we should create new classes of tools that really are for non-programmers, that do things like hide the complexities of XML Schema and XPath. When the day comes that non-programming users are really building production-level RIAs, I'll wager long odds that they won't be doing so by editing XML XPath node-set expressions in Notepad.

Of course, like all good bookmakers, Bill won't be losing any money on a prediction like that (although he may not find too many punters prepared to hand over cash either). But whilst I too want to see exactly this revolution in application development, I feel that it is not about to happen any time soon because the languages being used to try and write such applications are still rooted deeply in the procedural past.

In fact, the reason I leapt on XForms about three years ago, was because at the time I was actually trying to build UIs that were based on RDF schema, but was finding it painful to build the necessarily dynamic UIs--if I used HTML it was too underspecified, and if I used C++ or Java you just spent too much time adding new features.

But the combination of XForms, XHTML 2, SVG and XBL does provide a platform which could be used to build the next generation of applications and as Bill wants, the next generation of application-builders. Of course, whether that happens sooner rather than later will depend on the people who are currently trying to offer ever more sophisticated internet applications; it will depend on whether companies like Yahoo!, MSN and Google continue to give developers old-style APIs--as Google Maps has done--or whether they adopt a new approach for the new generation of RIAs and RIA-builders.

---

Tags

ruby on rails | Programming | aop | aspects | formsplayer | xforms | webapps | web2.0 | rest | rdf | semweb | xbl | ajax

Notes:

1: I did find a simple 100-line script, but it only shows one feed, and the URI for that feed must be specified in an input box. The XForms RSS Reader takes about 450 lines of XHTML and XForms (plus some additional CSS), and allows the saving of a number of feeds with all of their details and current values--in other words a pretty much full-featured reader.

2: It's interesting that Microsoft have also decided that RSS readers shouldn't be so difficult to write. They are building into Vista a component that will track feeds and place the data into some sort of store which can then be retrieved by various viewers and applications.

3: As it happens Ruby on Rails works quite well with XForms. I'll try to find time to show a demonstration of this in action.

4: And just in case anyone missed Bill's point, Rob McDougall follows it up with a 'comment' on the blog:

As you [Bill] point out, it's common for advocates of declarative grammars with specific targets to oversell the general usefulness of their solutions.

I don't know how "common" it is for anyone to advocate a declarative approach. Most of the blogosphere is taken up with dicsussion of AJAX and Ruby on Rails which are far more trendy, and their advocates wouldn't touch a declarative model with a barge-pole. So you may accuse me of "overselling", but I don't see it being "common". (Although T. V. Raman, formally of IBM and now of Google, may protest that he is 'overselling' declarative mark-up just as much as me.)