On My Way To Japan

It's 7:15 am at SeaTac Airport, about twenty minutes south of Seattle. My plane for Japan leaves in about an hour, after a brief layover in Vancouver. I get to ride a Mosquito hopper betwixt here and BC, one of those odd little throwbacks to the age of the prop plane that makes one think a little more favorably about the comfortable accomodations of today, even in cattle car flights. I've had about four hours of sleep (t'was dead on my feet after trying to find a decent power converter at 11 pm, dealing with two kids that were way too amped up to get to bed, and trying to get presentations done. It'll be a close call whether or not the presentation gets done before the class starts, but with luck things will fall into place.

The battles have already begun, however. Currently there is, within the sXBL group, a fairly heated discussion about whether XPath or CSS should be the default language for chosing selectors for template content. This little bit of arcana may be new to you, especially if you missed the announcement that sXBL had been released recently. For those whose W3C acronym dictionary may not be completely up to date, sXBL is the SVG specific XML Binding Language. The purpose of this particular language is to accept arbitrary XML (mostly) as input and generate through a series of templated transformations and event calls, a dynamic SVG tree. Many may know this technology under its somewhat older name RCC, part of the spec released last year at around this time, that did the same thing.

sXBL serves somewhat of the same purpose as XSLT, except that it is designed to work in an event driven environment on specific nodes rather than as a single transform against a complete XML document. This means that if some facet of the document changes (i.e., an event is received at some point in the tree) then the event will initiate transformations for the effected nodes automatically. This has a number of applications beyond SVG; it's currently used within Mozilla to perform shadow tree HTML implementations from external XML sources, for instance, and the idea of being able to create a dynamic interactive XML oriented application has applications in any ckind of modelling, simulation, gaming, or interface context. Consequently, it is likely that XBL will end up having very much the same kind of cascading effect upon the development community that XSLT did, far beyond its original focus.

The current controversy stems from the question of which selection language to use: XPath or CSS. From a data-binding orientation - which I basically see sXBL as being), XPath makes far more sense - it is designed to be able to retrieve specific nodal and subnodal properties, such as text and attributes, without requiring any Javascript or related code. This improves its portability, makes it easier to generate sXBL from external transformations, and radicaly simplifies accessing content from one schema inside of another display schema. The CSS side argues that XPath is too complex, too heavy-weight for vendors to support, and is inaccessible to beginning users. This is likely a red-herring, as sXBL is nearly as complex as XSLT, just in its own way.

The challenge of finding a good binding language is critical for this specification, as it will likely start making its way into the newly fired up development process of several browser vendors in short order. I would be interested in hearing other people with arguments on sXBL, and specifically the binding language issue, in order to try to present something at the conference.

Flights leaving soon, so I'll wrap this up.

-- Kurt