Recipes for remixers

Interfaces that are XML-based and schema-backed can lay a kind of contractual foundation for layered extensions. This idea applies equally to Web applications and to smart documents that use the Microsoft or OpenOffice XML formats.

Formal contracts aren't just stabilizers, they're enablers. If documents were predictably structured, for example, we could visualize their change histories in even more compelling ways. Yet there's a reason why Wikis and Greasemonkey are gaining traction, along with the RESTful approach to Web services.

Contracts are awkward beasts, and they generate a lot of friction. Of course, some friction is a good and necessary thing, but if we can't make contracts easier to use, the grassroots ecosystem will continue to route around them. And that's not in anyone's best interest. [Full story at]

In answer to the question I'd asked earlier in the week -- How do you design a remixable Web application? -- this column suggests making the implied contract between a Web application and its human or robotic user into something more explicit.

Of course we're always searching for that sweet spot between not enough formalism and too much. In the realm of Web services, REST gives us the freedom to innovate but not -- as Phil Windley noted -- the power to intermediate easily and reliably:

Over the past two years, I reviewed a lot of intermediaries for SOAP. They are made usable by WSDL. Without WSDL, using one of these would be such a chore, that you're never do it. Every time you wanted to configure a new service intermediation, you'd have to custom describe the API. [Phil Windley: Toward More Sophisticated Intermediation]

WSDL is an enabler for service intermediation, but that first step is a doozy. Hence various proposals for a more humane service description language from Rich Salz, Norm Walsh, and Tim Bray. As more applications produce and consume services, the ability to remix the applications will partly depend on our ability to intermediate their constituent services. A simpler and REST-friendlier kind of WSDL could help us do that.

But the folks who are remixing applications nowadays aren't just intercepting service invocations and transforming data. They're also intercepting and transforming interfaces and behaviors. Although Greasemonkey is a convenient (and thus popular) way to hook in, you can do all the same stuff in proxies, in which case it looks a lot like service intermediation.

How might we make interfaces and behaviors more explicit, and thus more open to reliable intermediation? On the interface side, we have a flock of description languages, such as XUL, MXML, and XAML. On the behavior side, there's a rich tradition of programming techniques, such as inheritance and delegation. We don't need to reinvent these disciplines. We do, however, need unify them to create a model that is easy to learn and can attain broad reach.

Former URL: