Another entry into what I hope is a short series of blogs about different approaches to data binding. My goal is to provide some perspective for the data binding discussions in the Java Desktop Network Components - JDNC project. A few weeks ago I wrote Data Binding in Laszlo - Lessons for JDNC and before I'm done I hope to cover Avalon and JGoodies binding.

In Browser/HTML applications data binding is often accomplished on the web server by replacing variables in a "template" HTML file with the string representation of live data values. Despite the infinite number of design options for web application elements like template syntax or template variable lookup, it seems as though every conceivable possibility has been enshrined in someone's custom web application framework. Over the years the design landscape has become cluttered with these shrines, their developers, and the wreckage left behind by the usual internecine warfare.

More recently web application frameworks have emerged that do much of the data binding work in the browser itself. Requesting raw data from the web server (or posting new data to the web server) and dynamically building the DOM for an HTML GUI is well within the capabilities of moderately portable JavaScript and modern browsers. Typically data and templates are encoded with XML. This new design landscape has been christened AJAX (Asynchronous JavaScript and XML), and browser developers are enthusiastically staking out real-estate for new web app framework design ziggurats.

XUL is not new and this isn't a blog about AJAX or web applications. I just wanted to write a little bit about how data binding appears to be supported in XUL, using XUL templates. If the first couple of paragraphs have left you wondering if you really possess the will to read all the way to my conclusions at the end, here's a shortcut to the exit: I don't think XUL templates are a good way to define data binding. I have a feeling that even some of more fervent XUL advocates would agree on this point. I also think that anyone who's managed to read and comprehend the RDF documentation deserves a medal and a vacation.

This blog isn't an introduction to XUL either. Suffice it to say that XUL is an XML schema for defining Mozilla browser extensions and browser based application GUIs. It's important because it's part of Firefox and Firefox is hot.

Using templates for data binding in XUL is a bit like using Javascript to construct a DOM in the sense that in both cases the binding process takes place in the browser. The XUL template enables specifying bindings in terms of what XML text (XUL source code) should be generated, rather than rough and ready DOM hacking. A XUL template is an XML file that contains template elements which produce XUL source at runtime. XUL templates operate on data represented as a graph, using RDF (lots more on RDF below).

The basic structure of a data bound XUL document is roughly:

<?xml version="1.0"?>
<window 
  xmlns:html="http://www.w3.org/1999/xhtml" 
  xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  ... 
  <vbox datasources="my-RDF-data.rdf" ref="urn:root">
    <template>
      <rule>
        <conditions> ... </conditions>
        <actions> ... </actions>
      </rule>
    </template>
  </vbox>
  ... 
</window>

The RDF graph of data that the templates will bind to is specified by the datasources attribute of an enclosing GUI container. In this case that's a vbox (vertical layout box) which also names the logical root node for the graph. Each template element in the file has a set of conditions. Conditions are expressions that get unified with the graph, and (shades of Prolog) cause expression variables to be bound to data graph nodes. These variables are substituted into the actions to produce the template's data bound XUL source code.

If you're interested in a complete example, take a look at the XUL Template Primer on the Mozilla.org site.

My take on this approach to specifying data bindings is that it makes the common case, binding data lists and objects to lists and form GUI components, difficult. The process of unifying rule expressions with subsets of the data graph to capture references to nodes that will be substituted into the template's actions, is difficult to explain and it's difficult to justify given the common case. Harsher criticisms of XUL templates exist, e.g. Why XUL Templates are a Waste of Time . I can't muster anything close to that much venom however I've only looked at the documentation and some examples. The other problem with XUL templates is the data encapsulation layer - RDF.

RDF (Resource Description Framework) is an graph based data encapsulation. Arcs in the graph are defined as "predicates" that link a "subject" node and a target or "object" node. An RDF document contains subject/predicate/object triples that collectively define a graph. Here's an example that dispenses with the usual RDF XML notation:

   JoeBlogs firstName "Joe"
   JoeBlogs lastName "Blogs"

These two subject/predicate/object triples define a graph with three nodes: JoeBlogs, "Joe", "Blogs" and two arcs: firstName and lastName.

Although it's possible to model any data type with RDF, some types seem to suffer for the encoding. Most JDNC applications are based on data that is most naturally described as lists of objects with attributes. As you can see from the example, defining an object's attributes as arcs is straightforward, although perhaps not as straightforward as a more conventional encoding, like:

List elements are related to the subject list itself with a predicate that defines the object element's one-based position in the list. Using the usual abbreviations, that's something like:

MyList rdf:type rdf:Sequence
MyList rdf:_1 myListElement0
MyList rdf:_2 myListElement1
MyList rdf:_3 myListElement2

One other aspect of RDF that trades readability for generality is that all three elements of each subject/predicate/object triple is defined by a URI. URIs (think URLs) are globally unique identifiers which means that, in theory, each triple means the same thing in all contexts on any computer, anywhere, ever. OK, that's something of an overstatement depending on what "mean" means. To really marinate in this topic, check out section two in the RDF Primer . Defining everything in terms of a URI exacts a big readability penalty. The previous example might be written like this:

<http://www.sun.com/myRDFScope/examples/JoeBlogs> 
   <http://www.sun.com/myRDFScope/examples/predicates/firstName> 
<http://www.sun.com/myRDFScope/examples/Joe> 

<http://www.sun.com/myRDFScope/examples/JoeBlogs> 
   <http://www.sun.com/myRDFScope/examples/predicates/lastName> 
<http://www.sun.com/myRDFScope/examples/Blogs> 

As you might expect, one can throw the usual XML and URI syntax tools at this to reduce the textual weight of an RDF document. For an example, take a look at the '.rdf' files that come with your Firefox distribution.

Frankly, I find it hard to believe that the average developer would have the patience to wade through the entire RDF specification or the RDF Primer for long enough to completely understand it. Even the Primer contains enough mind numbing passages to frighten away all but the most dedicated reader. For example:

Note that asserting the reification is not the same as asserting the original statement, and neither implies the other. That is, when someone says that John said something about the weight of a tent, they are not making a statement about the weight of a tent themselves, they are making a statement about something John said. Conversely, when someone describes the weight of a tent, they are not also making a statement about a statement they made (since they may have no intention of talking about things called "statements").

A developer with no greater ambition than to just put a list of customers or account balances on the screen, is likely to be considering a career change by the time they've finished with this material. I found myself sobbing uncontrollably.

In conclusion, I'll just repeat the point I made earlier. I don't think XUL templates represent an approach to data binding that would be wise to incorporate into JDNC and I don't believe using RDF to encapsulate data is practical given the density of the RDF specifications.