This has been a bad month for the Scalable Vector Graphics movement Because of a developing family medical crisis, I’ve had to step down from chairing the SVG Open 2006 conference, a decision which, combined with other issues that the conference has had, led to the mutual decision by the SVG Open board to cancel the conference this year and hold it in 2007. This decision was hard to make, given the importance that this conference has for many people and not a few companies, but it is also a reflection of larger factors that have seriously buffeted the standard over the course of the last year.

Adobe this week made an announcement that was, while not unexpected, yet another blow - they were choosing to stop supporting the Adobe SVG Viewer in any fashion, to make it unable for download by the end of the year and to effectively dismantle the last vestiges of SVG outside of the fairly secondary roles that that standard plays in Adobe products in favor of their own FLEX language, acquired from Macromedia during the merger last year.

Meanwhile, work has effectively stopped on the Mozilla Firefox SVG implementation, at least until after the release of Firefox 2.0, and while it is certainly hoped that the program will be continued the rumors at this point are somewhat grim, with the very real possibility that SVG is considered to be disliked politically by certain factions within the organization in favor of the WHATWG Canvas specification.

There are points of light in all of this darkness: the release of Opera’s superb SVG 1.1 implementation in their Opera 9.0 product shows that a dynamic SVG implementation within the browser is both possible and feasible, the Batik project, after having sat dormant since 2003, has gained new life, Inkscape is very rapidly becoming the default vector program for the Open Source community, and both commercial and community efforts in SVG are definitely showing that SVG is capable of meeting at least some of the tasks at hand.

However, I think that there are times that it is necessary to step back and seriously evaluate any technology, asking whether in fact that technology has what it takes to be viable. There are more than a few fairly significant issues that SVG has fallen short on. As an evangelist of the technology, I am in a position where it behooves me to overlook the bad in order to promote the good, but I also need to remain objective enough to understand why SVG has failed where it has in order to suggest ways that the technology can either be improved or to suggest that perhaps SVG has no business being in certain arenas.

SVG has always been a somewhat challenged technology, because it struck at the heart of one of the core functions of any and every operating system - the rendering of what you see on the screen. With the exception of rendering icons, operating system graphics engines are fundamentally vector engines - adept at designating rectangles, circles, shapes and regions, together with brush and fill patterns and text handling routines. Given the concerns coming from operating system vendors (and not just those in the commercial camp), SVG initially started out as a considerably underpowered standard that lacked such things as text flow regions, the ability to cleanly handle 2.5D features such as “3D” borders, more robust gradients, layout managers, and a host of other features that for the most part made many operations problematic at best. At the same time, the animation capabilities that did end up in the standard, while quite cool, also significantly degraded the performance of SVG applications.

The SVG specification was also seriously hampered by the attempt to make it the first RAND (Reasonable and Non-Discriminatory) W3C standard, an effort that was brought about in part by the larger stakeholders in the standard who felt that there was too much potential for SVG to be potentially competitive with their own product lines and wished to see some parts of the technology licensed.

I’ve always felt that when the W3C refused to endorse the RAND standard in their charter, Adobe’s interest in participating in the evolution of SVG dropped off dramatically. The business reason at the time was no doubt sound, and I know from discussions with Adobe at that time that there was still considerable interest in the standard, but the merger with Macromedia (which obviously saw a potential for conflict with SVG to their own core Flash (and now FLEX) products) insured that the actions this week were nearly unavoidable.

SVG’s commercial track-record has also been more than a little frustrating. A number of companies have invested a considerable sum of money and programmer resources in order to develop SVG viewers, yet the market for such viewers is more threadbare than it was even a couple of years ago. Corel, before it was bought out, had perhaps the second best SVG viewer (and it was reasonably close in a number of areas) but the industry interest was lukewarm at best. Whether it eventually contributed to the dismemberment of that company is always debatable, but from the standpoint of the SVG community it was a blow. I’ve had numerous friends and business acquaintances who have tried their hand at creating such viewers (or of building businesses around the standard). Most are now engaged in other activities that are only peripheral to the field, their projects and products so much roadkill.

I think that a part of this has come because of the fact that XML languages in general have taken considerably longer to achieve adoption than most people, myself included, ever thought possible. XSLT 2.0 is very nearly out of the standards process some six years after the first version was released, and XSLT 1.0 is only now just really beginning to gain pervasiveness of adoption (to the extent that many now entering into the AJAX realm or only just beginning to discover the power of AJAX + XSLT … a topic of which I will have far more to saw in a future post). XForms, despite having been pushed out the door in 2002, is finally beginning to get some uptake and momentum.

XML languages are, for those of us enmeshed in them, surprisingly simple to work with if your world consists of transformations, pipelines, bindings, rich data models and distributed programming. It is why I have to occasionally re-examine my own assumptions as a writer when I talk to people about XML, because for a great number of people, XML exists largely at the periphery of their own programming or systems management experience. SVG faces this issue even more acutely than other languages do because as a language it exists at a level of abstraction one removed from even something like HTML.

I need to explain this. HTML (or XHTML, to stay within the XML vernacular) ultimately is a language for abstracting the display of a particular form of document, in this case a web page document. You could not use XHTML to display vector graphics. However, if you consider that SVG is a graphics language on par with Postscript (and its successor PDF) or GDK(+) or any other graphical standards, then there is comparatively little that would stop you from using a transformation on HTML in order to create SVG for the actual display of content. The fact that there are some limitations that would prevent this attests to my initial assertion that SVG 1.0 (and 1.1) was underpowered, though whether SVG 1.2 has in fact solved that is debatable.

The point, however, is that even given this, SVG is a much lower level language, and one that quite properly only comes into its own either in very graphical applications (such as geographic information systems) or when mediated through some form of binding or transformation language - XSLT, XBL or some similar mechanism. Indeed, I daresay that even GIS applications work better for bindings.
A binding basically takes a high level object model (such as information describing the various components of a map) and creates an association between each element of the object model (for XML expressed as XML elements) and an underlying implementation in a lower level language.

An illustration here can prove useful. Let’s say that you have a map that shows houses on a street. You can of course render this directly in SVG, drawing the various elements in their respective locations, but the information contains comparatively little external information, making it difficult to update it except by being very diligent in commenting. On the other hand, with a binding, you could do such things as take a reference to a <house> object, declared as something like:

<house>
    <map_reference>C11125A5</map_reference>
    <map_coordinates units="km" x="1.252" y="2.1442"/>
    <lot_coordinates units="m" path="M0,0 L0,25 30,25 30,0 0,0z"/>
    <house_coordinates units="m" path="M8,7 L8,18 24,18 24,7 8,7z"/>
    <owner>Kurt Cagle</owner>
    <address>
        <street>1313 Mockingbird Lane</street>
        <city>Victoria</city>
        <province>British Columbia</province>
        <country>Canada</country>
        <postal_code>V8N3R2</postal_code>
    </address>
</house>

and with the binding render this object as the appropriate graphical entity in SVG. The distinction between a binding and a transformation in this regard is simple - a transformation performs the mapping between the XML of the house object to its appropriate SVG representation, while a binding effectively monitors the house object and its subordinate DOM members and then forces a change in the representation (perhaps by calling a transformation) when the underlying model changes. In my experience, a binding that also calls a transformation is perhaps the best of both worlds, but that’s outside the scope of the present article.

One point to note here - bindings do not necessarily need to be set up on each element of a given XML DOM. In the above example, for instance, there may be comparatively little benefit to placing bindings on <map_coordinates>, for instance, if the <house> object is “atomic”, though if most objects include a <map_coordinates> object, then there may be some. Good bindings, like good schema design, require a trade-off between flexibility and efficiency.

Bindings thus have a huge impact upon SVG. Without them, most SVG objects end up being either built in code by hand or end up being generated from a graphical editor that generally tries to optimize for performance rather than legibility (or programmability). This is not to say that SVG as a general transport format doesn’t have its place, but this assumes a fidelity of translation between systems that SVG currently does not yet possess to any meaningful degree - especially compared to such things as postscript, which has a twenty five year legacy to overcome.

The W3C Working Group had spent nearly three years developing a binding language, which has undergone a number of both design and name changes over the course of its life. Its latest incarnation, sXBL, was a very minimalist interpretation of the binding requirements aimed largely at low memory system devices that didn’t necessarily support scripting. There is, of course, a danger with that kind of strategy, one that WML phone vendors found out to their chagrin - standards efforts take a significant period of time, and in that time the “minimal” bar will almost always improve dramatically. WML died out largely because it was too limited and ambiguous, attempting to create a subset of an existing standard (XHTML) even as cellular device manufacturers were reaching a point where their graphical interface systems could handle the rigours of XHTML.

The sXBL language is dead, killed by a decision recently in the SVG working group. While I was not privy to the discussions there, I suspect it had to do with the fact that an existing XBL standard - Mozilla’s XBL implementation I’ve discussed in previous columns - had become by far the most well known, and had additionally been pushed into the W3C as a draft. The new XML Applications activities are now working with what is increasingly looking like the Mozilla XBL 2.0 implementation, which includes support for both some form of programmatic interface and the relevant transformations of key elements (and about which I will also be writing more in upcoming columns). sXBL had become irrelevant.

Ot should be noted that a related SVG 1.2 specification, the getData() and postData() methods that were for a long time a part of the external data communication system within SVG 1.2 are also gone for precisely the same reason. The industry standardized on XMLHttpRequest, largely because of its flexibility and the recognition that in a distributed environment you need to have an asynchronous data communications protocol. However, rather than working with that component, the alternative was to come up with a generalized Connection object (http://www.w3.org/TR/SVGMobile12/svgudom.html#global__Connection) for low level socket level communication, one that is admittedly asynchronous, but that is nonetheless still using a custom set of APIs (and ones that are considerably lower level than most web developers are generally comfortable with). This would perhaps not be quite so egregious except for the fact that the XMLHttpRequest object is now on a fast-track for approval by the W3C itself.

This tendency to create implementations generally outside the industry norm (and outside the domain of other W3C technologies) has also been exemplified in the ongoing struggle between SVG and CSS. There is a fairly significant overlap between the two technologies, and whenever you have such an overlap, the sometimes strong egos involved tend to get in the way. I’ve worked with CSS since its inception, and while I have become quite proficient in its usage, I’ve never been a big fan of the fact that there has been no major effort (with the exception of the admirable work done by Doug Schepers) to create a standardized XML implementation of CSS. This would have a profound influence in most of the presentation formats that the W3C currently holds sway over, would make it possible to validate presentations in the same way that you can validate any other XML document, makes it much easier to build styles via transformations and so forth.

However, the ongoing competition between CSS and SVG has largely stymied that effort. There are personalities involved, and the personality clashes and conflicts have been responsible for a significant amount of the delays involved in seeing the standards out, have created incompatibilities in the W3C stack in a way that makes it far more difficult to use the pieces together cohesively, and I suspect may also be responsible for a great deal of the perception on the part of first tier implementers that these conflicts mean that they should hold off on the implementation of standards such as SVG.

I see signs of this elsewhere in the W3C stack, and it angers me. The DOM activity was closed down a few years ago in the belief that its work was done, leaving the world with the verbose and often unwieldy DOM API and providing no convenient hook for extensions, despite the fact that such extensions are emerging via such things as E4X. Is E4X by itself within the mandate of the W3C? No - its obviously by its name (ECMAScript for XML) that it is rather a curious appendage of the ECMA’s only standards efforts - but in truth the many efforts of creating an objective XML language - in Java, JavaScript, Python, Perl, C#, Ruby, PHP and so forth - point out that the world, or at least its developer community, finds the arcane and verbose DOM standard to be too unwieldy for their use. I have to wonder if the relative indifference to SVG is a tacit response to that same frustration.

Yet for all of this, I am not ready to pronounce the SVG standard dead yet, not in the face of so much evidence to the contrary. Opera’s efforts in this regard are notable - with a native SVG implementation already in their 9.0 browser, Opera has basically done something truly necessary to the survival of the standard - it has created a native implementation within the browser, rather than forcing users to go the route of plugins. SVG is also finding its way to the Apple Safari desktop (and like all that Apple does, will likely be fast, efficient and really sexy). I believe that with SVG on Opera, this will likely be a burr in the saddle to Firefox to get their own implementation of SVG completed, which only leaves Microsoft …

Adobe has left the building. Microsoft has recently release their second 7.0 beta, and its status as a stop-gap seems at best only to be confirmed by this - IE7 would have been a really cool browser in 2002. In my list of career regrets, not going to Microsoft to take up that challenge looms large, though I suspect now more than ever that I would have been the wrong person for the job. The truth at this stage is that for Microsoft, SVG on 7.5 makes an incredible amount of sense - it actually provides a bit of technology jujitsu against Adobe (which now has its own Flex language that it is pushing at very opportunity), it works well in the strategy of moving IE to a pure XHTML browser, something which lets them recapture some of the market that they’ve lost to Firefox in the enterprise space, provides an update for the aging VML language which is itself nearly a decade old, and can act as a stepping stone to adoption of other Microsoft XML technologies, including their own WPF/XAML efforts.

This last point needs a little explanation. XAML has been the bogeyman for SVG developers since its inception. XAML is a considerably larger and more complex effort, dealing with pieces of UI far removed from the province of SVG in addition to its obvious graphical domain. The problem with this approach is that XAML is also a compilation oriented language that necessitates having a fairly robust run-time available … or of using system resources such as JavaScript and native graphical implementations such as SVG in order to create a proximal application on platforms such as OSX. XAML is, from discussions with Microsoft, too heavyweight for even earlier versions of IE, especially in the face of sandbox and security concerns.

However, if Microsoft had its own native SVG implementation, it can in fact use the same proximal WPF routines that it does for the Apple code, and an SVG component is considerably lighter-weight than XAML is - making it easier to pass the viewer as an internal update to IE. This also helps to push the notion of transformational bindings (and lets them additionally recapture momentum) in a flavor that is more beneficial to Microsoft’s interests than letting other projects such as Firefox push that particular technology. It gets the excellent LINQ technologies in front of web developers and ultimately positions the IE browser as being the gateway to future technology rather than being seen as a rather crusty has-been.

Microsoft made a fairly strategic error about six years ago, one which it is paying for now. In an effort to reignite the declining shrink-wrap model, they made a decision to stagnate the browser - it would eventually merge back into the operating system. The decision backfired on them in a major way. Electronic resources, including software, video, music and so forth, increasingly exist only in downloadable format or even just as distributed BitTorrent clouds. The only thing keeping the software industry from collapsing entirely is the degree of ethics that most people adhere to, and that is rapidly slipping in the face of the benefit/penalty ratio. This means that for most people, the browser continues being the most used application on the desktop. Firefox by itself is a pretty decent browser, but Firefox with an army of extension developers becomes serious competition to the Windows desktop.

As an aside, with of course perfect 20/20 hindsight, Microsoft’s best strategy would have been for them to concentrate on building up XAML not as a stand-alone (and bloated) XML platform but rather as an XML-based tool for adding extensions to Internet Explorer in the way that XUL is used now for Firefox, then let third party developers take the lead from there. I suspect this would have caused a massive gold rush to the new IE platform in the same way that there was the initial rush of vendors to the early Windows platforms, and would have basically energized the Windows market. However, the problem with hindsight is that the should haves are generally only apparent after the dids are etched in stone.

So this brings us back the SVG. SVG 1.2 Tiny will be going golden in October or November, assuming that someone doesn’t decide to stand in the way again. It’s a solid specification, with much credit to Chris Lilley, Dean Jackson, Nandini Ramani, Robin Berjon, Erik Dahstrom, Doug Schepers, Antoine Quint, Andreas Neumann and the others of the SVG working group who have given up the last couple of years of their lives in order to see this spec out the door. It nicely rounds out many of the limitations that I see with the SVG 1.0 specification, making it the product it should have been. Moreover, given what I’ve seen of adoption of SVG elsewhere, this is the important specification, probably the definitive SVG specification for 1.2 - SVG 1.2 Full will likely not see daylight for some time to come, and it will draw heavily upon Tiny when it does.

I’m older now … my daughters delight in counting not the stray white hairs in my beard, but the increasing clumps of white. With that age comes a certain degree of acceptance - the world is never as good as you hope, nor is it as bleak and dark as you fear. Adobe’s decision to exit that field has opened up a vacuum, but vacuums tend to fill up of their own accord. I believe that SVG’s heyday is actually still ahead of it, but it will take wider spread adoption of binding-based programming in order for it to live up to its potential.

With bindings, the underling low level rendering capabilities become less relevant - SVG or XAML or Flex will all work, and indeed with a consistent binding architecture in place (which I see emerging) this opens up what I see as one of the more exciting potentialities - you build applications by creating a common binding framework which can work on object-oriented schemas to render to the local environment in the manner that is most appropriate. Within the Flash environment, this would be Flex, Microsoft could use WPF/XAML or possibly a JavaScript/SVG basis, while everyone else utilizes that last combination for their own apps.

In the long run, this is perhaps as it should be. One of the arguments that has been made by many companies, Microsoft perhaps foremost but far from alone in this, is that the danger that standards have is that they tend to force homogenization on all adoptees of those standards, usually at the level of the most minimal implementation. While this gives developers a chance to compete, it also penalizes those who have the resources to move beyond these core capabilities.

On the other hand, by creating a common binding layer, an abstract analog to a CLR or similar system, I believe this opens up some very real possibilities for companies to have their cake and eat it too - building differing implementations that still work to accomplish the same relevant tasks between platforms, but give the platform developers the latitude necessary to show off their own system capabilities to the best potential advantage.

Will it happen this way? I don’t know, though my instincts say yes. The Kudzu principle (”XML expands until it replaces all available processes in a system”) argues that XML will almost certainly end up being the dominant messaging architecture in a system over time (and why I believe that REST will likely dominate over RPC/SOAP, if it comes to that). I see binding architectures as the next logical step in that process, and in so doing, feel that SVG plays a critical part in the presentation layer of that architecture, as the graphical layer of choice in those systems where a proprietary binding is not as critical.

These troubles too will pass. I’m no longer actively involved with the SVG Open conference (at least not for a while) as I deal with family issues that are more critical to me personally, but I will continue to support the technology in my writings and through behind the scenes efforts. Please check out http://www.svgOpen.org for updates about what is happening with the conference, and I ask if you are interested in any way with Scalable Vector Graphics that you look at ways that you can become involved by contacting the organizers directly.

Kurt Cagle is an author and software developer living in Victoria, British Columbia.