You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
249 lines
10 KiB
249 lines
10 KiB
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta name="generator" content=
|
|
"HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 13), see www.w3.org" />
|
|
<meta http-equiv="Content-Type" content="text/html" />
|
|
<title>
|
|
-- Axioms of Web architecture
|
|
</title>
|
|
<link rel="Stylesheet" href="di.css" type="text/css" />
|
|
</head>
|
|
<body bgcolor="#DDFFDD" text="#000000" lang="en" xml:lang="en">
|
|
<address>
|
|
Tim Berners-Lee<br />
|
|
Date: 1998, last change: $Date: 2010/03/02 02:48:47 $<br />
|
|
Status: personal view only. Editing status: first draft.
|
|
</address>
|
|
<p>
|
|
<a href="./">Up to Design Issues</a>
|
|
</p>
|
|
<hr />
|
|
<h1>
|
|
Principles of Design
|
|
</h1>
|
|
<p>
|
|
Again and again we fall back on the folklore of the
|
|
principles of good design. Sometimes I need a URI for them so
|
|
this is started as collection of them. I have written about
|
|
some in many places. Principles such as <b>simplicity</b> and
|
|
<b>modularity</b> are the stuff of software engineering;
|
|
<b>decentralization</b> and <b>tolerance</b> are the life and
|
|
breath of Internet. Brian Carpenter has enumerated some
|
|
principles of design of the Net [<a href=
|
|
"Architecture.html#carpenter">carpenter</a>]. The third pair
|
|
of ideas I have found commonly useful for the Web. I
|
|
mentioned them in a keynote at WWW7 and the note on <a href=
|
|
"Evolution.html">Evolvability</a>.
|
|
</p>
|
|
<p>
|
|
This is largely "motherhood and apple pie" but it still needs
|
|
a home.
|
|
</p>
|
|
<h2>
|
|
<a name="KISS" id="KISS">Simplicity</a>
|
|
</h2>
|
|
<blockquote>
|
|
<p>
|
|
"Keep it simple, stupid!"
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
Simplicity is easily to quote but often ignored in strange
|
|
ways. Perhaps this is because it is the eye of the beholder.
|
|
</p>
|
|
<p>
|
|
A language which uses fewer basic elements to achieve the
|
|
same power is simpler.
|
|
</p>
|
|
<p>
|
|
Sometimes simplicity is confused with 'easy to understand".
|
|
For example, a two-line solution which uses recursion is a
|
|
pretty simple, even though some people might find it easier
|
|
to work though a 10-line solution which avoids recursion.
|
|
</p>
|
|
<p>
|
|
In XML, "Processing Instructions", those things which start
|
|
with "<?" are <strong>not</strong> simple. They look
|
|
simple, just an extra sort of thing in the language, but the
|
|
complicate what was a very clean design of elements and
|
|
attributes, and a complication in the underlying syntax is
|
|
has great effect. All specifications which refer to XML
|
|
processing will have to figure out what to do about
|
|
processing instructions as well as elements.
|
|
</p>
|
|
<h2>
|
|
<a name="Modular" id="Modular">Modular Design</a>
|
|
</h2>
|
|
<p>
|
|
When you design a system, or a language, then if the features
|
|
can be broken into relatively loosely bound groups of
|
|
relatively closely bound features, then that division is a
|
|
good thing to be made a part of the design. This is just good
|
|
engineering. It means that when you want to change the
|
|
system, you can with luck in the future change only one part,
|
|
which will only require you to understand (and test) that
|
|
part. This will allow other people to independently change
|
|
other parts at the same time. This is just classic good
|
|
software design and books have been written about it. The
|
|
corollary, the TOII is less frequently met.
|
|
</p>
|
|
<p>
|
|
Modular design hinges on the simplicity and abstract nature
|
|
of the interface definition between the modules. A design in
|
|
which the insides of each module need to know all about each
|
|
other is not a modular design but an arbitrary partitioning
|
|
of the bits. <a href="Modularity.html">(More ...)</a>
|
|
</p>
|
|
<h2>
|
|
<a name="Modular2" id="Modular2">Being part of a Modular Design</a>
|
|
</h2>
|
|
<p>
|
|
Its is not only necessary to make sure your own system is designed
|
|
to be made of modular parts. It is also necessary to realize that
|
|
your own system, no matter how big and wonderful it seems now,
|
|
should always be designed to be a <em>part</em> of another
|
|
larger system.
|
|
</p>
|
|
<p>This is often much more difficult than modularity.
|
|
</p>
|
|
<h2 id="Tolerance">
|
|
Tolerance
|
|
</h2>
|
|
<blockquote>
|
|
<p>
|
|
"Be liberal in what you require but conservative in what
|
|
you do"
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
This is the expression of a principle which applies pretty
|
|
well in life, (it is a typical UU tenet), and is commonly
|
|
employed in design across the Internet.
|
|
</p>
|
|
<p>
|
|
Write HTML 4.0-strict. Accept HTML-4.0-Transitional (a
|
|
superset of strict).
|
|
</p>
|
|
<p>
|
|
This principle can be contentious. When browsers are lax
|
|
about what they expect, the system works better but also it
|
|
encourages laxness on the part of web page writers. The
|
|
principle of tolerance does not blunt the need for a
|
|
perfectly clear protocol specification which draws a precise
|
|
distinction between a conformance and non-conformance. The
|
|
principle of tolerance is no excuse for a product which
|
|
contravenes a standard.
|
|
</p>
|
|
<h2 id="Decentrali">
|
|
Decentralization
|
|
</h2>
|
|
<p>
|
|
This is a principle of the design of distributed systems,
|
|
including societies. It points out that any single common
|
|
point which is involved in any operation trends to limit the
|
|
way the system scales, and produce a single point of complete
|
|
failure.
|
|
</p>
|
|
<p>
|
|
Centralization in social systems can apply to concepts, too.
|
|
For example, if we make a knowledge representation system
|
|
which requires anyone who uses the concept of "automobile" to
|
|
use the term "http://www.kr.org/stds/industry/automobile"
|
|
then we restrict the set of uses of the system to those for
|
|
whom this particular formulation of what an automobile is
|
|
works. The Semantic Web must avoid such conceptual
|
|
bottlenecks just as the Internet avoids such network
|
|
bottlenecks.
|
|
</p>
|
|
<h2>
|
|
<a name="TOII" id="TOII">Test of Independent Invention</a>
|
|
</h2>
|
|
<blockquote>
|
|
<p>
|
|
If someone else had already invented your system, would
|
|
theirs work with yours?
|
|
</p>
|
|
</blockquote>
|
|
<p>
|
|
Does this system have to be the only one of its kind? This
|
|
simple thought test is described in more detail in "<a href=
|
|
"Evolution.html#TOII">Evolution</a>" in these Design Issues.
|
|
It is connectted to modularity inside-out: designing a system not to be
|
|
modular in itself, but to be a part of an as-yet unspecified
|
|
larger system. A critical property here is that the system
|
|
tries to do one thing well, and leaves other things to other
|
|
modules. It also has to avoid conceptual or other
|
|
centralization, as no two modules can claim the need to be
|
|
the unique center of a larger system.
|
|
</p>
|
|
<h2>
|
|
<a name="PLP" id="PLP">Principle of Least Power</a>
|
|
</h2>
|
|
<p>
|
|
In choosing computer languages, there are classes of program
|
|
which range from the plainly descriptive (such as Dublin Core
|
|
metadata, or the content of most databases, or HTML) though
|
|
logical languages of limited power (such as access control
|
|
lists, or <em>conneg</em> content negotiation) which include
|
|
limited propositional logic, though declarative languages
|
|
which verge on the Turing Complete (Postscript is, but PDF
|
|
isn't, I am told) through those which are in fact Turing
|
|
Complete though one is led not to use them that way (XSLT,
|
|
SQL) to those which are unashamedly procedural (Java, C).
|
|
</p>
|
|
<p>
|
|
The choice of language is a common design choice. 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.
|
|
</p>
|
|
<p>
|
|
Computer Science in the 1960s to 80s 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 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 the cunning Java applet. While this might allow a very
|
|
cool user interface, it cannot be analyzed at all. The search
|
|
engine finding the page will have no idea of what the data is
|
|
or what it is about. This the only way to find out what a
|
|
Java applet means is to set it running in front of a person.
|
|
</p>
|
|
<p>
|
|
I hope that is a good enough explanation of this principle.
|
|
There are millions of examples of the choice. I chose HTML
|
|
not to be a programming language because I wanted different
|
|
programs to do different things with it: present it
|
|
differently, extract tables of contents, index it, and so on.
|
|
</p>
|
|
<hr />
|
|
<h2>
|
|
<a name="References" id="References">References</a>
|
|
</h2>
|
|
<p>
|
|
<a href="ftp://ftp.isi.edu/in-notes/rfc1958.txt" name=
|
|
"carpenter" id="carpenter">B. Carpenter, Editor:
|
|
"Architectural Principles of the Internet"</a> Internet
|
|
Architecture Board, June 1996, RFC1958
|
|
</p>
|
|
<hr />
|
|
<p>
|
|
<a href="Overview.html">Up to Design Issues</a>
|
|
</p>
|
|
<p>
|
|
<a href="../People/Berners-Lee">Tim BL</a>
|
|
</p>
|
|
</body>
|
|
</html>
|