XML-based declarative user interface languages are becoming all the rage right now. While the ability to declare a GUI using a descriptive language is nothing new (I believe software for X-Windows/Motif widgets has been around for awhile), we are seeing this renewed focus due to several factors: 1) maturity of XML technologies on the web, 2) the rising popularity of Mozilla's Firefox browser, 3) next release of Windows (Longhorn) and 4) new web applications that provide an enhanced user experience over traditional web experiences (for example Gmail, Google Maps, Flickr).
1) Mozilla: How about XUL and XBL?
The Mozilla Foundation has been working on producing an open source browser for some time and have finally hit the mainstream with their Firefox browser. The layout and user interface "engine" of the browser stands on two languages: XUL (XML-based User interface Language, pronounced "zool") to describe the widgets and layout of a user interface and XBL (eXtensible Binding Language, pronounced "zibble") to bind the widgets to event handlers, extend XUL widgets, etc. For an executive summary, see here. The languages have been around in some form or another since 2001.
2) W3C: Hmm... We say XForms
It seems clear that Mozilla wanted the W3C to support XUL and XBL as web standards. The style of the XUL spec matches that of the W3C specification document styles. More convincingly, there is a W3C page for XBL submitted in Jan 2001. However it is mentioned that "This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. W3C has had no editorial control over the preparation of this Note. ".
I guess the real problem is that W3C was already working on a standard for a XML-based user interface language called XForms initially put forth in October 2001 as a draft by a working group consisting of people from Adobe, IBM, Novell, Sun, etc. I notice that no one from Netscape/AOL/Mozilla is in this working group, but maybe I'm misinterpreting things. Maybe the web browser was simply not viewed as an application platform at this time, and thus there were no browser developers invited?
3) Microsoft: Nope, it's XAML
Microsoft is working feverishly to get Longhorn out the door and a big feature of the upcoming Windows release is supposed to be XAML (eXtensible Application Markup Language), which is (as you probably guessed) a XML-based declarative user-interface language written by Microsoft. This short history of XAML mentions that a motivation for XAML was to make a "persistence format for .NET objects". i.e. a text file that would describe the layout of .NET user-interface objects like Buttons, Windows, etc.
One major difference between XAML and XUL/XForms is that XAML also includes vector graphics. This means you can specify polygons, lines, ellipses, fonts, paths and do arbitrary transforms on these vector graphics (shears, translations, rotations and scaling).
Does this last bit sound familiar? This brings us neatly to the next corner of our multi-cornered boxing ring:
4) W3C: Ok, what about SVG and sXBL?
I've been spending a lot of time learning about SVG (Scalable Vector Graphics) right now and getting excited about it's potential. SVG is starting to build some steam on the internet: we're seeing a few web browsers with native support for SVG (Opera 8 has good SVG Tiny 1.1 support released in April, Firefox 1.1 builds have partial SVG Full support and should be released next month, KSVG an extension to the Konqueror browser also has some SVG support). [By the way, this made me curious about Microsoft's Internet Explorer, but my hopes were quashed when I read that the new Internet Explorer 7 will not yet support SVG. <sarcasm>I wonder if it will support XAML any time soon<sarcasm>]
Anyway, SVG supports a lot of functionality, including vector and raster graphics, fonts, embedded media types (like audio, video), gradients, filters, transforms, hyperlinks to other resources, the ability to animate pretty much everything and a sophisticated series of events that can be acted upon via scripting languages such as EcmaScript. Of course all SVG elements and attributes are accessible through the DOM as well.
This means that SVG is a huge, almost all-encompassing specification for graphics, text, audio/video, animation, and user interaction on the web (hey, kinda like Flash). Given enough incentive, I could envision a day (in the FAAAAR distant future) when SVG could be the "root" document and completely replace HTML as the document format of choice on the web. Of course this would require significant backing by the web community (in terms of browser and publishing software) and a whole lot of work developing SVG to support sophisticated user-interface controls (such as checkboxes, list boxes, pull-down boxes, etc like this). And this is where we come to the next tidbit:
About a week ago, a new W3C-proposed specification came out for initial review called sXBL which stands for "SVG's XML Binding Language". This specification is being worked on by representatives from Adobe, Apple and Opera. The representative from Apple (David Hyatt) just happens to be the same guy who wrote the Mozilla XBL 1.0 specification. A blurb at the top of this specification states: "sXBL is intended to be an SVG-specific first version of a more general-purpose XBL specification (e.g., "XBL 2.0")". Notice that they mention XBL 2.0 here. You probably guessed that XBL 1.0 is the Mozilla version of this language submitted way back in January of 2001 and it seems like you'd be right. In fact, a (currently empty) section in the document is titled "Comparison of sXBL to XBL1", in which Mozilla guy "Nigel McFarlane has kindly offered to write an appendix describing the differences between Mozilla's XBL and the sXBL language defined by this specification.".
So the idea is that you have SVG defining your graphics capabilities or "engine" and defining various "widgets", then you have sXBL that allows you to binds the various widgets to behavior and presentation.
5) OASIS: You guys are all wet. UIML! UIML! UIML!
Work apparently began in 1997 on a standardized language for representing user interfaces. This is apparently right around the time that XML was being invented/proposed, so it may be the oldest XML-based user interface language out there. Apparently UIML is being standardized by OASIS though the latest document I could find on any website is UIML 3.0 (2002) which still has "DRAFT" on the cover. I know even less about UIML than I do about XAML, sXBL and XUL, but I learned of it while skipping through some Wikipedia pages on this topic so I thought I'd include it here to illustrate how many different XML-based user interface languages are currently out there. (Hint: Don't go invent your own!)
And The Winner Is?
Unfortunately I don't know how to end this long and windy entry because I've only spent a couple hours doing cursory research here. Furthermore, I'm also heavily biased towards SVG at this stage.
Anyway, I'll put a few summarization statements out there in an effort to draw some flimsy conclusions:
- Though I haven't mentioned it above, there is another contender here (non-XML based) and that is Macromedia's Flash. Flash is proprietary and non-open, but it is currently VERY widely supported as a browser plugin.
- SVG is a standard supported by the W3C, but currently with only a couple plugins and minor native support in three browsers (that I know of). It is often touted as a competitor to Flash with the potential for more.
- Microsoft's popularity in the desktop and browser arenas will ensure that XAML will become widely supported on Windows platforms and (probably) on the web via enhanced Internet Explorer support
- in order for Adobe to compete, it will feel the need to push for standards other than XAML. Adobe has traditionally been leaning heavily behind SVG (contributor to spec, wrote the de-factor SVG plugin, ASV)
- I guess where the dough is made on this is in the publishing software, NOT in the freely available plugins or browser renderers (though if XAML is widely supported that means I'll be using IE do my browsing so there is that factor to consider)
- with Adobe & Macromedia pending merger, they will have a very large footprint (dominant) in the publishing software space
- Flash will (probably) never be natively supported in a browser as it is not a non-proprietary standard. This means that it would be up to Adobe/Macromedia to keep extending Flash, updating and distributing the plugins, etc.
- another argument against Flash is that it is non-XML-based and it is clear that the XML bandwagon has taken off.
Thus it seems to me that Adobe will promote SVG by making sure all of its publishing software supports SVG output. With continuing support from browsers and plugins like Renesis, and the growing mobile market, SVG popularity will grow in the next few years. Flash will die a slow death or be reborn somehow as an extension/optimization to SVG (hey, that name is awesome, it certainly beats the pants off of "SVG").
So in the end, you'll have SVG competing with XAML for rich and interactive web graphics. I think XUL+XBL will stay in its niche position within Mozilla. Maybe someone within Mozilla will rework XUL to be an extension of SVG waaaay down the line since they are both XML-based?
I think we'll also see lots of translators from XAML to SVG and back again such that all of this competition will probably (in the end) really amount to how each company can differentiate themselves by extending each language. Unfortunately this reminds me of the Browser Wars between Netscape and Microsoft that were/are still being battled in the realms of JavaScript, CSS and the DOM. "I see a bad moon a-rising"...
sXBL (pronounced “sexball”)