RESTful And Social Internet Applications

Mark Birbeck is always thought-provoking, as a thinker and prototyper on the frontier of next-generation Internet Applications. I particularly appreciate his perspectives on metadata and microformats.
Mark recently posted an example of a Link Manager Written in XForms. This and some of Mark’s earlier examples, such as XForms-based RSS Reader really show off the potential power of XForms as well as the appeal of the sidebar approach to extending the browser as a platform. However, these sample applications to me also show that declarative model-based application construction “without programming” 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. If you are really going to be implementing programmatic algorithms, having to use cumbersome XML markup with a fixed set of atomic actions and only work-arounds to enable looping amounts to programming with boxing gloves on. And while XForms doesn’t prevent scripting, if you are going to have a major script component in your RIA, then would XForms really be buying you much in the first place? A big part of the appeal of emerging frameworks like Ruby on Rails is the elimination of XML configuration spaghetti in favor of a focus on simpler, more streamlined code. As a coder this makes a lot of sense to me. And with introspection and other techniques tools can do a lot of analysis on programmatic code – further diluting the supposed advantages to programmers of declarative approaches.
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. 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.

One Response to RESTful And Social Internet Applications

  1. I agree that declarative grammars have limitations that procedural grammars do not. Likewise declarative grammars have strengths over procedural grammars for certain applications. In my view grammars range from solving certain specific problems (such as representing a particular data model) to those that try to solve more general sets of problems (such as programming languages). The more general a set of problems a grammar was intended to solve the better a procedural grammar is in solving those problems. The more specific the problem to be solved, the more likely a declarative grammar will present advantages over a procedural grammar in solving those specific problems.
    In the end, there if one creates a graph of generality vs. suitability, declarative grammars start with high suitability and fall off towards the middle of the graph. The opposite holds true of procedural, its suitability would start low and then rise as generality increases. This is natural and makes sense. (Don’t get me wrong, I don’t think this graph is symmetrical. I think the procedural suitability is significantly higher in the specific end of the graph than declarative is on the general end)
    As you point out, it’s common for advocates of declarative grammars with specific targets to oversell the general usefulness of their solutions.
    I think your you’re right XForms misses the mark on simplicity mainly because of inclusion of various other standards like XML Schema and XPath that have missed the sweet spot where a declarative grammar makes sense by trying to be too general. They (or perhaps we because I was in the group) caved to internal W3C pressure to leverage existing W3C specs. I applaud the HTML group for holding strong against pressures to include unnecessary XLink complexity in future XHTML grammars. Keeping the grammar targeted, simple and elegant is the secret to creating a good declarative grammar. In this regard, less is more.