The Technical Architecture Group at the W3C doesn’t write specifications per se, it comes up with “findingsâ€. Those are guidelines and recommendations for how to make better use of technologies.
Good guidelines and recommendations are hard to write, incidentally why they’re more valuable than specs. They’re the result of real use, hands-on experience and the right level of constraints. At least more so than other working group documents.
In late February the W3C TAG released a document titled “The Rule of Least Power“. From the abstract:
When designing computer systems, one is often faced with a choice between using a more or less powerful language for publishing information, for expressing constraints, or for solving some problem. This finding explores tradeoffs relating the choice of language to reusability of information. The “Rule of Least Power” suggests choosing the least powerful language suitable for a given purpose.
In the first section they highlight the main principle:
Principle: Powerful languages inhibit information reuse.
If you ever tried to connect two systems together, you know what they’re talking about. Languages that are simple are also easy to work with. You can get something up and running in hours and build from that. All mightly languages tend to suck weeks out of your life before you get to “hello worldâ€. And that’s when the real work starts.
They follow the principle with a good practice:
Good Practice: Use the least powerful language suitable for expressing information, constraints or programs on the World Wide Web.
(For those not in the know, “good practice†is spec committee speak for “best practiceâ€.)
There’s an interesting law here. The more powerful the language is, the more you can talk about the language. But the least powerful the language is, the more you can do with the language.
Now, throw in the network effect and something interesting starts to happens. The more people can use the language, the more data and services you have. And the more data and services you have, the more data you can accumulate and more services you can build.
In short, simple languages accomplish more.
HTML is a great example of that. Look at the Web, it thrives on a language that’s easy to learn, easy to use even if you’re making every HTML violation in the book. It will still show up in search engines, you can still store it and print it, you can tag and bookmark it.
More recently mashups, greasemonkey scripts and scrAPIs. They don’t use composable XML documents with namespaces, typed schemas and mustUnderstand extension points. They use HTML warts and all, a little bit of scripting, and get amazing results for little pain. They’re proof that the least powerful and more common language is the most suitable for expressing information.
I added “more common†to the TAG principle. Common means you can use it more ways than one, more often than anything else. That gets you the network effect. HTML works with any programming language you can use on the Web, from bash CGI scripts all the way to Rails. If you’re writing new code you can find plenty of libraries and examples to work with. If you’re just using it, you get plenty of services that can read and spit HTML, transform it, search it, store it.
There’s only one sore point in the W3C finding, which comes up later in the document:
If, for example, some weather data is published as a Web resource using RDF, a user can retrieve it as a table, perhaps average it, plot it, or deduce things from it in combination with other information.
What if, for example, some weather data is published as a Web resource using HTML? A user can retrieve it as s table, perhaps average it, plot it, or deduce things from it in combination with other information. Sounds like a mashup to me.
But a user can also look at it and print it through the magic we call Web browser. And a user can have it on their desktop as a Firefox extension, or an AJAX widget. A user can also integrate it into their Web site, as a live real-time feed. And I’m sure you can think of more interesting ways to use it that are all possible today.
RDF is a great idea for expressing graphs of information and coupled with OWL something you can talk about for ages. But users are not interested in talking about graphs of information, they’re interested in using weather reports. RDF is not common, not simple and not getting things done.
Like I said in the beginning, coming up with good guidelines and recommendations is a difficult act, even the W3C falls on the occassional trap. But still, the finding is a good read and I recommend the recommendation. They also give JSON proper credit, which makes up for everything else:
Specifically, JSON provides for standalone use of a declarative subset of the literal declaration syntax from the JavaScript language.