Understanding XML

YOU.

In this day and age of IRC and e-mail, you would be called “The SVG Community.” That means that, for the most part, you spend as much time, perhaps more, talking with people half a world away about the difficulties of getting viewers capable of rendering real time animations (or even not-so real-time) animations, the building and binding of component architectures, the glacial speed at which the standards process moves or the latest Adobe/Macromedia merger than you do discussing local politics, the current scandals involving high priced sports figures or the dating problems of the latest curvaceous actress.

I hate to tell you, but there's something just a little bit ... odd ... about you. Most people, at the end of the day, walk out of their office cubicles and their office lives at the glass office door. It's just a job, after all. You ... you read documents with titles like “Compound Document by Reference Use Cases and Requirements Version 1.0” ... and what's worse, you read them at home, and get spitting mad when you come across something that seems assanine. This is not normal behavior!”

So why do you do it? Huh? I'll hazard a couple of guesses here. You do it in part because the subject is fascinating to you – the idea of intelligent pictures is, when you get right down to it, one of those subtly archetypal images that smacks of hobbits and dragons, and the idea that you can make that happen is admittedly pretty cool. Yet even that doesn't quite explain it all ... after all, Macromedia Flash did the same thing nearly seven years ago, and multimedia applications have been a staple of computing for a long time.

Personally, I think there's something else there that is in, it's own way, much more important, and it is the same reason that I do this too – that I am as much of this community as you are. You do it because you care about the future. You do it because you realize that ultimately locking up our words and images – the two things that ultimately make us human - behind the walls of proprietary software and proprietary institutions hinders communication, lock people without the means to buy into the “game” to a form of fiscal servitude ... that or risk falling into the information abyss.

The notion of open standards is an odd one, one that is sometimes difficult to explain in light of the more well-known open source software, and its a comparatively recent one. For many years, companies have conducted business by exploiting the differential between information formats, either by making it too expensive or troublesome to switch to another format in order to assure lock-in to that company's technologies, or by providing those conversion services themselves – for a price. A standard is in essence an agreement to speak a common language. An open standard is the further agreement that anybody can speak that same language, that one didn't need to speak some form of secret “club-speak” known only to its members.

Riffing on Open Standards

Open standards is a powerful concept, and it works against the status quo. A number of big companies have given lip service to such open standards as SVG – in a few cases even making a serious effort in that direction -- then backing away as they began to realize the potential danger that may emerge to their own software efforts. Smaller companies (and many open source communities) on the other hand recognize that their best strategy is to make their products utilize open standards that can in turn be used with an increasing constellation of other products and projects that also use these standards. They are admittedly forced to compete on that one quality that most companies prefer not to compete on – quality. To these companies I'd say “Guys, I'm sorry about that, but I'm frankly a lot happier seeing you compete on quality than on the degree to which I have to rely upon your product because I can't move away from your format.”

You're all evangelists of one stripe or another, because you look at technologies such as SVG and see in it a means to make it easier to communicate (a singularly useful skill for a messenger, after all). I think a few of us (okay, maybe all of us) wish that this process was going faster, but its worth putting things into perspective. Two years ago, I had to explain to most programmers I worked with what SVG was. A year ago, I had to explain to most non-programmers I worked with what SVG was. Today, companies are hiring SVG developers, SVG is on our phones, is moving into our browsers, is appearing in embedded display systems on our trains and planes. This did not happen in a vacuum. It occurred because you took the message of SVG, of open standards, into your workplace, into your schools, into your government offices.

The future never arrives as fast as you think it should, yet the world is always stranger than we could have imagined when it does. You'll go home after this conference thinking of binding components and that elusive specter of an open 3D format, of creating art with words and mapping the realms of our planet and our minds. What you'll also be carrying home, something of immense value but which you should probably be able to get through customs, is a seed of the future. Help that seed grow – your children and grandchildren will thank you for it.

About the Future of SVG and Web Technologies

On to the crystal ball gazing, there are a few interesting trends to be aware of moving forward. Note that none of these are “predictions” per se ... they are instead observations that I've culled from talking to current “bleeding edge” developers and users.

• SVG Is Not Enough.. SVG by itself is an interesting graphical format, and no doubt there will be hundreds of thousands of SVG clip-art pieces out there within the next few years. However, SVG by itself is not strong enough to carry forward technologies without both some higher order organizing mechanism (a web application schema such as an XBL) and frequently ancillary technology such as XHTML, XForms or XUL. Increasingly, presentation oriented XML will tend to be namespace-rich, and tools that specialize just in SVG will be overshadowed by tools where SVG can become part of the namespace.
• Bindings, Bindings, Bindings! Data Binding is the process of mapping the contents of a data source into a component. Component Binding is the process of mapping an abstraction of an interface into its presentation. Whether Mozilla's XBL, the W3C's sXBL, Microsoft's XAML presenter components, such bindings of XML will likely increasingly be the way that applications are built. In many cases, the combination of the two types of binding can significantly reduce the overhead of both creating and maintaining applications, and because you are dealing with the abstraction of an interface, the underlying mechanisms for implementing the individual components can easily be changed from platform to platform while maintaining cross platform integrity. SVG will likely be only one target of many for such presentation systems.
• Ecmascript for XML (E4X). This ECMA standard (and similar ones) convert XML element structures into Javascript objects but still enable XML-related operations such as XPath and XSLT transforms. E4X simplifies most XML operations, to the extent that you could represent a set of SVG g objects with identifiers as svg..g[@id]. E4X is part of Mozilla, and it is entirely possible that it may be a part of Microsoft's suite by 2007.
• 3D XML (X3D). X3D is an XML version of the 3D OpenGL standard. It has been paired with SVG in the past and will do so even more in the future (perhaps to the extent of SVG being rendered as X3D textures). While 3D apps such as games may very well be part of this language's legacy, my suspicion is that more likely the 3D will be in support of 2 ½ D interfaces where the 3D support “pushes” the 2D architecture partially up out of the plane of the page.
• Native Support Trumps Plugins. Plugins are dying within browsers and other applications for a number of reasons – security, lack of DOM transparency, distribution issues. This trend will likely continue, though it will also be accelerated by the increasing prevalence of SVG as a core service within the rendering architecture. Linux KDE and Gnome currently support an SVG rendering component (KSVG in KDE, Librsvg in Gnome). Apple will be adopting the KSVG, and it is likely that KSVG will tie into an native vector rendering engine (though the rendering engine itself may be proprietary). Similarly, SVG's dominance is becoming strong enough that SVG will ultimately become a supported format for Avalon, the graphical architecture for Vista, though again, it will likely be an “interpreted” format there – declarative SVG will be converted to XAML (raising another argument against extensive DOM manipulation and for binding architectures). All browsers will support SVG import by 2008, with most (IE being the exception, except with a plugin) by 2006.
• The Browser As Framework (XGUIs). XML Graphical User Interface Languages (XGUIs) are XML based frameworks for the development of both GUIs and, increasingly, non-GUI services. Mozilla exemplifies this approach today, where the Firefox browser, Thunderbird newsreader, Sunbird calendar system and so forth are all essentially built with lower level XML-abstracted components in XUL. Microsoft's XAML will take a similar approach. Such services offer the potential of complete JIT applications built around these framework components.
• The Age of Skinnable Applications. Similarly, SVG and related presentation languages make increasingly possible highly specialized applets that can be spawned and supported by a central local server that run on the desktop, that can be themed or skinned by their users transparently and that break out of the box (rounded rectangles or not) in highly original ways (and without the need for extensive low-level programming experience). Put another way, while the original look and feel of an application may be set by the application designer, that it will stay that way is debatable. Moreover, skins may (will, actually) include customized functional extensions. That this has an effect on product branding should be obvious.
• Plug and Play I18n/L10N. Internationalization and localization were the great challenges of the 20th century. XUIL architectures make possible the modularization of these services (with a well designed component architecture), with these resources likely stored in XML files that can be swapped on the fly.
• Syndication Replaces the Web Page. Syndication makes it possible to both create a collection of related entities on the web and to generate a train of payloads. The IETF Atom 1.0 specification in particular bears watching here, as it is a wholly XML oriented solution that supports and understands name-spaces. Syndication is fundamentally REST oriented, and as such fits into the natural architecture of the web in a way that SOAP really doesn't, and has already begun replacing some of the more low-hanging service oriented fruits. Note that syndication also may play a big part in a simple web event architecture.
• AJAX Fades, Need Doesn't. AJAX (Asynchronous Javascript and XML) has become something of a buzzword of late (as a synonym for the increasingly ubiquitous but cumbersomely named XMLHttpRequest object). AJAX services will likely be replaced by declarative tags (Xinclude, anyone?) at some future point, but the idea itself, of replacing single page content in which state is destroyed between pages with a non-destructive query or transmission to a server that can preserve state is very likely the new web paradigm.
• The Editable Web. We spend billions of dollars making the web editable in proprietary ways, usually by attempting to do it using server-oriented programming. This has long struck me as being analogous to attempting to knit a sweater by telephoning in each stitch – it's certainly doable, but it's hideously expensive, has very little flexibility, and usually ends up producing an abysmal result. XForms, rich browser-based WYSIWYG editors, graphical state changes encoded in SVG and similar technology will put the editing back on the client (where it belongs) while simultaneously reducing the server load so that it can do what it does best, which is serving content rather than attempting to preserve state across transactions. This also moves editing out of web panes and into the browser itself, which can expose much more extensive functionality.
• Ubiquitous Personal Content. The idea of remote file editing has been around for a while, but it has long been tied to the processes of the transaction through ad hoc APIs. An open standards publishing API (Atom 1.0 Services) makes it possible to standardize on the publishing of disparate content information types, and raises the possibility of not just publishing written material but dynamic content, forms content, application user preferences and so forth in a transparent manner. The user preferences are particularly intriguing as it raises the possibility of being able to log in on any machine at any time, establish your identity, and then have your applications configure themselves to reflect the previous session's settings, including research marks, annotations, and themes.
• Rise of Domain Experts, Not Programmers. XGUI based systems separate the abstract representation of applications from their implementation, which means that increasingly (likely using tools) specialized programmers will be replaced by domain expert non-programmers. This is already happening in fields like GIS. GUIs for designing such XGUI applications will similarly look more like flash editing tools or web layout tools with a few “access points” into scripting exceptions than they will complex IDEs. This doesn't make programmers obsolete, but it does increasingly push them into a component developer role.
• Data/Platform/Language Independence. XML is increasingly abstracting the form of data access, turning complex and arcane queries (and updates) against LDAP servers, SQL databases, web services, mail services and so forth away from dissonant technologies and towards common XML ones. XML based XGUIs abstract the underlying platform interfaces and turn them increasingly into XML-oriented virtual machines that can degrade gracefully in the face of more limited capabilities, and makes such religious issues as Java vs. C++ vs. C# vs. flavor of the month language irrelevant – you use what works on the system to implement the abstraction. This doesn't eliminate the need for software – you still need to have those component implementations, and many of them may be extraordinarily complex and specialized in the back end, but it goes a long way toward eliminating the need for re-engineering the 90% of actions that we still do using the web now, from gaming to e-commerce to communication.

It should be worth noting that none of this will happen overnight. There will be resistance on the part of the status quo to almost every point given here. Moving more control to the client sells fewer server boxes and server licenses. Data independence lowers the differentiation between data providers. Skinnable applications reduce the ability of the application designer to completely set the look and feel of a product and places it in the hands of the user. Bindings and component architectures reduce the role of the programmer and architect to commodity producers.

So why do all the trends seem to point in the above direction. Part of it is because “Software as a Service” is largely a myth, a convenient marketing meme that certain software companies in particular have sought to promote in order to preserve their dominance (or potentially even their existence). Software ultimately should facilitate communication – either between people, between people and their desired goals within the computer system or between systems. The increasing abstraction of interfaces plays into the hands of the domain experts, who are ultimately the ones who are paying for the software in the first place. In some cases this manifests as open source projects (which are as often as not domain expert rather than programmer driven, especially the more useful ones).

In other cases the move towards XML architectures occur because commercial providers failed to understand the customer's needs, or because those same customers realized the dangers of turn-key systems. In even others, tightened budget constraints and a fear of code lock-in have brought software development in-house, and in general the solutions which are most successful are those which are led by the domain specialists, not the IT staff, because those domain specialists know their own needs.