Principles.html
10.2 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
<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>