Extending Tractor Beams The Importance of Bindings
Several speakers have made the pronouncement that while AJAX is powerful, it's not QUITE there yet. And I'm inclined to agree for a number of reasons though perhaps not the ones that people had in mind. In 2005, Tim Berners-Lee gave a keynote address at the World Wide Web Conference in Japan where he pointed out that the insecurities plaguing Web browsers were a direct result of the introduction of scripting language within the confines of the Web browser.

Understanding why such a blanket statement, one perhaps at odds (though in the long run I don't think it is) with what was covered at the AJAX conference, should be both made and be true can go a long way towards understanding where the Web itself is going, and certainly where Web development is heading. There are a number of key insecurities about immediate scripting that make the Web more fragile:

• Platform Incompatibilities: Each incompatibility offers both a chance for code to break and for rogue code to get through. While a common framework here would be desirable, vendor differentiation makes that framework difficult to achieve.
• Cross-Domain Scripting: As AJAX programmers, we want to have the freedom of getting out of the sandbox, but the security restrictions involved in such sandboxing make certain sense.
• Intermingling and Poor Code Reuse: Too much JavaScript is cut and pasted, often out of context or without consideration of side effects. Toolkits help, but even they can be used as crutches and limit the options of what a developer can do, especially in an enterprise context. Managed code in the business environment is important, if not critical, which is part of the reason that uncontrolled coding in a Web environment makes IT managers as leery as Scotty with a misaligned transporter coil.
• Lack of Validation: With such cut-and-paste code, it also makes it far more difficult to validate the code, because it's typically developed in a production environment at production deadline speed.
• Poor Abstraction and Maintainability: JavaScript code is more susceptible than most when it comes to the generation of unmanageable code, and such code management is the lifebread of enterprise IT.

Given all these factors, is there any real alternative around there? I believe that there is, and it's one that many third-party vendors have of course twigged onto. This alternative is XML Binding, which can be thought of as the following:
An XML Binding is the association between an XML element in a presentation environment and some form of functionality from an external "binding document" that persists beyond a single presentation generation. Properties for the bound element can, in turn, be set via attributes, or from associated methods defined from the binding itself. Such a binding is also known as a behavior.

What this means in a nutshell is that you can introduce XML tags into your presentation documents (XHTML or otherwise), define a binding or behavior on those tags then let this underlying behavioral functionality control the interactions with clients in the application.

Such XML Bindings can cover a lot of different functionality. A short list of such bindings include such things as:

• Page Layout Elements: This includes oriented boxes, containers, flexible spring controls, stacked boxes, tabsets, wizards, and similar components.
• Data Fed Elements: Undisplayed data providers (both static and dynamically refreshing, such as a news feed reader), dynamic tables, XForms data models, Live treeview components, and so on.
• Graphical and Animated Elements: Defined or complex generated shapes, charts, graphs, bound image components, animated clocks. and other widgets.
• Secondary Applications: Some tags may also contain whole applications ­ slideshow widgets, image selectors, IM windows, and so forth.

In short, such XML Bindings give you all you need to effectively create either primary applications (an insurance application) or subordinate infrastructure (such as a notification widget in a Web page) and can do so without necessarily requiring an extensive amount of server-side programming.

Most commercial and open source XML frameworks are built on the notion of bindings in one fashion or another, although whether the ability to define subordinate components from those frameworks is implementation-dependent. Languages such as Mozilla XUL, Adobe FLEX, Microsoft XAML, Laszlo SystemsLZX, and so forth are all built in this same way, though being able to build components (which is what XML binding is all about) that can be directly integrated into Web page flows varies considerably from app to app.

There are a number of different languages for handling binding, the most notable of which, Mozilla's XBL, can be used to create components directly in Web pages as well as in the Mozilla application itself. Most of these languages create a one-to-one association between the XML object and a given class written in a language such as JavaScript, with the additional notion that the component constructors, methods, and properties are aware of (and shadow) the XML element being bound. The class, in turn, becomes responsible for rendering the content to be seen in the tag (I've often found that coupling such a binding with XSLT works miracles here).

Such bindings offer a huge win for enterprise development in particular:

• Standardized Library: Code can be created in isolation and then added to an enterprise library of useful objects, making it much easier for IT managers to control code workflow.
• Separation of Skillsets: A component developer is a considerably more difficult person to find than Web designers and developers, so by creating specialized XML bindings you can keep such developers focused on building components rather than spending all of their time marking up code.
• Security: Such components, being tested in isolation, can be introduced independent of production timeflows and can be made appropriately secure. Moreover, such components can also perform secondary implementation ­ bootstrap code that pulls in what should be private coding will only function if the page is within the appropriate security context, so people can't follow a URL to get a source code library.
• Code Maintenance: With XML Bindings you can keep your XML contained in a single block without the need for additional inline scripting. This abstracts the application, making it easier to read and change under the hood so long as you're not changing the XML interface, making it much easier to maintain in the long run.
• Platform Flexibility: An additional side effect of such bindings is that in limited-capability devices the XML from the source code can be transformed directly on the server, and the bindings themselves can be amended to handle device-specific implementation details. This masks the need to have a common development framework, something that's currently limited with AJAX.

What is perhaps most significant is that it's possible now to create binding layers for most, if not all, browsers by using JavaScript. In some cases (specifically Mozilla Firefox and Internet Explorer) native binding languages do exist. In the short to mid-term, this points to needing to create specific bindings for each platform, though effective use of the XBL (or emerging XBL2) standard can mitigate the actual work considerably.

I see XML Bindings as being the logical progression of AJAX over the course of the next two years although the technology exists today in somewhat disparate form. It's likely that the adoption of such XBLs will actually take place more in the corporate sphere where browser use can be mandated and the component use consequently not limited by the need to build "super-controls" than it will in the wider Web, at least first, but over time many of these components should move into the mainstream of Web development just as JavaScript "framework" libraries are used today.

The Final Frontier
The efforts going on in the Web right now are not a radical revision of the past, but rather a refinement and "refactoring" that is at the heart of nearly every software endeavor, and it is this refactoring, far from obvious for those in the thick of it but profound nonetheless, that is ensuring the integrity of the Web. We are moving to a model where we have both an imperative model for power and a declarative model for structure, something near and dear to an old engineer's heart, and it will be both glorious and, more to the point, elegant, when it is done. May you, gentle reader, boldly go where no one has gone before.