About skimming

The skim architecture is primarily about bouncing across the top of numerous sets of data, briefly touching before 'bouncing' on to the next. Skimming implies that we don't get too involved in each of these services, and instead, like a stone being skimmed across a lake, we skip from server to server. It therefore implies that our servers increasingly become nothing more than sources of data with a published API. And our clients become powerful enough that they can interact with any server we want them to.

The key idea of the skim architecture is to not be 'tightly bound' to some server, since this makes the data and UI intertwined. Instead we want to be as 'light' as possible. That means servers should deliver information via technologies like REST, RSS, XQuery, RDF and so on. Of course we want to build platform-independent applications, but instead of achieving it by constantly porting our server-side applications to new environments, we want to achieve this by defining a set of simple APIs.

And why do we want such loose coupling? Because ultimately, server-side mash-ups do not scale. Tomorrow I might decide to add more information that I hadn't thought of today. Or you might want to use a different source of information to me; you might want your country drop-box to show the country names in French, I might want to use Google Maps instead of Yahoo! Maps. Without the skim approach we have to either update the original mash-up, or build a new mash-up that aggregates the old one and adds the new data sources.

Another feature of the skim approach is that standard mark-up languages are used for everything. skim divides the languages into the core and UI; XHTML, XForms, XML Events and RDFa are common to any environment, whilst UIs may make further use of rendering languages such as SVG, SMIL, X3D, MathML, CSS and SSML.

This group of languages we've called xH. The same mark-up can be used in many environments, not just a browser; xH applications could run on a server, in a standalone web application viewer, in a side-bar, toolbar, system tray message...even as a widget inside another xH application. For xH there is no distinction between a desktop application, a web application, a server-side application or a reusable widget.

Yet by depending heavily on standard languages--and using declarative mark-up--we are leveraging the skills we already have, allowing us to focus on the logic of building applications...not the spaghetti.