This document is also available in these non-normative formats: XML.
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 explains the Principle of Least Power, which suggests choosing the least powerful powerful language suitable for a given purpose.
This document is an editors' copy that has no official standing.
This document is a first draft of a proposed finding. It has been produced by the W3C Technical Architecture Group (TAG). The text of this finding was adapted from Principle of Least Power in [Axioms].
Additional TAG findings, both accepted and in draft state, may also be available. The TAG may incorporate this and other findings into future versions of the [AWWW]. Please send comments on this finding to the publicly archived TAG mailing list email@example.com (archive).
The terms MUST, SHOULD, and SHOULD NOT are used in this document in accordance with [RFC 2119].
When publishing information or programs on the Web, the choice of language is important. The low power end of the scale is typically simpler to design, implement and use, but the high power end of the scale has all the attraction of being an open-ended hook into which anything can be placed: a door to uses bounded only by the imagination of the programmer. Computer Science in the 1960s through 1980s spent a lot of effort making languages which were as powerful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The reason for this is that the less powerful the language, the more you can do with the data stored in that language. If you write it in a simple declarative from, anyone can write a program to analyze it in many ways.
The World Wide Web is unique in its ability to promote information reuse on a global scale. Information published on the Web can be flexibly combined with other information, read by a broad range of software tools, and browsed by human users of the Web. For such reuse to succeed, the broadest possible range of tools must be capable of understanding the data on the Web, and the relationships among that data. By expressing constraints, relationships and processing instructions in less powerful languages, one increases the flexibility with which information can be reused.
HTML is designed not to be a full programming language so that many different things can be done with an HTML document: software can present the document in various styles, extract tables of contents, index it, and so on.
The Semantic Web is an attempt, largely, to map large quantities of existing data onto a common language so that the data can be analyzed in ways never dreamed of by its creators. If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. At the other end of the scale is the weather information portrayed by an ingeniously written Java applet. While the applet might provide a very cool user interface, the program cannot be analyzed at all. A search engine finding the page will have no idea of what the weather data is or what it is about. Thus, the only way to find out what a Java applet means is to set it running in front of a person.
Thus, HTML and the Semantic Web are examples of technologies designed with "least power" in mind. Web resources that use HTML and the Semantic Web are more likely to be reused in flexible ways than those expressed in more powerful languages.
The following should be considered before we publish.
Is it a principle? Roy suggests "no". Should the GPN stay? Is the title OK?
Tim BL to review.
Added reference to functional languages and Haskell OK?
New 3rd paragraph on "reuse on the Web" OK?
Existence and wording of GPN OK?
Separation of and minor rewording of section 2 OK? (Tim had everything in one section.)
Decide editor list.
Use RFC2119 uppercase terms? If not, remove from intro and bibref. I'm leaning against [NRM]
Tim's original claims the Java applet "can't be analysed at all". I've kept that for now, but it seems a bit strong. [NRM]
Editorial: "the attraction of being an open-ended hook into which anything can be placed" Mixed metaphor? Can you place something into a hook?