Working together for standards The Web Standards Project

Microsoft’s announcement of their new XML-based GUI language, XAML (pronounced ‘zammel’), at their Professional Developers Conference has focused attention on XML-based GUI languages. This is an area that has seen a tremendous amount of activity over the past few years, mostly out of the spotlight. Here’s a partial overview of the work done to date.

The W3C‘s answer to XML-based GUIs is a section of the SVG 1.2 working draft called Rendering Custom Content, also known as SVG-RCC. SVG-RCC specifies how arbitrary XML markup (say, an XForms element) can be transformed on the client into SVG for display to and interaction with the end user. These elements can then be styled using CSS and scripted via the SVG DOM. SVG-RCC is still very much a work in progress. At this time, it does not offer the sort of layout functions available in some other XML-based GUI languages nor does it offer the same range of prebuilt widgets. It also has limitations with regard to the reuse of SVG widgets on multiple, possibly disparate, elements. It does, however, represent one possible way to define the appearance of elements from disparate XML-based markup languages, such as XForms. Using SVG-RCC one could, for example, create a bar graph from an XHTML table.

Perhaps the oldest and best-known XML-based GUI language is the Mozilla Foundation’s XUL (pronounced ‘zool’). This is the technology used to define the interface for many Mozilla-based projects, including the eponymous Mozilla browser suite, the lightweight Firebird browser, the Thunderbird mail client and the Netscape browser suite. Safari 1.1 has also implemented a tiny bit of XUL. XUL is a markup language for defining the layout of user interface elements. The appearance (colors, borders, etc.) of these elements can be defined either using attributes or via CSS and images, such as PNG. Behaviors for these elements are defined with either interpreted ECMAScript or compiled C++ and interact with elements using the AOM, a superset of the W3C‘s DOM. Behaviors are attached (‘bound’) to XUL elements with XBL, a Mozilla technology which has been submitted to the W3C. These bindings are then attached to specific elements using either CSS or the DOM. While XUL makes extensive use of various W3C recommendations, and is in fact based on RDF, it is not itself a W3C recommendation, nor has XUL itself it been submitted to the W3C for consideration (only the XBL portion has been submitted). At present, XUL does not support SVG, XForms, SMIL or other UI-related W3C technologies, though there is no reason it couldn’t do in the future. There is, in fact, a project aimed at bringing SVG support to Mozilla, though the effort is still in its infancy.

Microsoft’s XAML is the newest entry into the XML-GUI arena, and the one that is most responsible for the recent buzz. It is in fact an integral part of the application development model for the next version of Windows (Longhorn). Since the final release of Longhorn isn’t due until 2006, XAML may yet change radically before the final release. XAML is an XML syntax for using Microsoft’s new vector-based drawing library, Avalon. Mac programmers will note that Avalon bears some similarity to Apple’s Quartz, which is based on PDF and OpenGL. Linux programmers will probably recognize the XML + vectors combination from both the GNOME and KDE desktop environments. None of the technology here is particularly new or unusual. What is (relatively) new is that raw XAML files can be viewed in the Longhorn version of Internet Explorer, sort of like XUL files can be viewed in Mozilla. XAML is used to create instances of ‘canvases’ (drawing areas upon which images, text and widgets are displayed), widgets like buttons and menus or shapes like circles, lines, bezier curves and so on. The initial appearance of these items is defined using attributes, as in XUL and SVG, or with an XAML-specific ‘style’ element. Behaviors can be defined with any .NET-compatible language (currently C#, VisualBasic.NET or JScript.NET) and are attached to elements either by embedding the code in a CDATA section of the XAML file or by accessing the widget via a tree-like structure similar (but not identical) to the W3C DOM. You can also define your own widgets and the like using a .NET-compatible language and then reuse them (‘instantiate’ them) using XAML. When using prebuilt XAML elements, like menus and buttons, you can view them in one of two ways: by compiling them and running them like any other Windows program, or by loading them into IE/Longhorn. If you use C# to define behaviors for a widget—whether the widget is one of the defaults or one you’ve created yourself—the widget must be compiled. Likewise, if you wish to run your XAML widget outside the browser, it must be compiled. Whether XAML widgets viewed within IE/Longhorn can use JScript.NET to add behaviors without compilation is, as yet, unclear. So is whether XAML widgets can be embedded in Web pages (with the obvious exception of HTML form elements, which will necessarily be XAML elements in IE/Longhorn) and whether XAML elements so embedded will be scriptable via ECMAScript and the DOM or stylable with CSS. What appears reasonably clear is that XAML eschews W3C recommendations like SMIL, SVG and the DOM in favor of similar—but incompatible—techniques unique to XAML.

How successful XAML will be outside Windows applications is hard to say. Adobe apparently has a plugin for AfterEffects that will produce XAML. Will other vendors follow suit? Steve Maine thinks so. He feels XAML will beat out other technologies because end users don’t care about platform independence. He’s right so far as he goes: most users don’t care that an application works on more than one platform; they only care that it works on their platform. Users of MacOS, Linux, various Unix flavors and even older Windows versions won’t be able to use applications that rely on XAML UIs. Judging by the adoption of previous Windows versions, that’s going to be a majority of users for a long, long time, even after Longhorn arrives in three years. As Jon Udell points out, that blows a pretty big hole in XAML‘s utility as a Web technology.

For more comparisons of XML GUI languages, see DonXML’s comparison of XAML and SVG-RCC, and Neil Deakin’s point-by-point comparison of XAML and XUL.

The three XML GUI languages above represent only a fraction of those available. Others include the Luxor toolkit, XWT, Java GUI Builder, Glade for the GTK+ toolkit used in the GNOME desktop, XML GUI Builder for the KDE Desktop, Laszlo Systems’ XML-and-ECMAScript Flash authoring software, Macromedia’s Royale Initiative and Kinesis Software’s Kinetic Fusion, a Java application that converts Rich Vector Markup Languag, Kinesis’ own XML-based vector graphics format, into SVG or Flash and back.

Post a Reply

Comments are closed.