Re: Is "simplicity" a useful architectural constraint?

/ "Cohen, Aaron M" <> was heard to say:
| Simplicity should be a goal, but not the only one. Solving the problem at
| hand has to be the primary goal. Someone famous (I can't remember who right
| now) once said that things should be a simple as possible, but no simpler.
| As that applies to the Web I think this means that the specs must be as
| complex as necessary to solve the stated problems, but not more complex.
| "The simplest solution that meets the design goals" seems to be a good
| operating principle for me.

I think this gets right to the heart of the issue. There are some
problems that are harder to solve than others and it's not fair (or
reasonable) to attempt to hold all specifications to the same
simplicity standard.

Everyone's favorite target these days is W3C XML Schema. It's big,
it's complex, it's hard to understand. But there was no way on earth
that it was going to be less than 100 pages because it attempts to
solve a very large, complex problem.

As I've watched this discussion go by, I've started to believe that
this problem has to be attacked from the other direction. Instead of
trying to solve all problems with the simplest possible specs, I think
we should be trying to solve the simplest possible problems.

If W3C XML Schema had been asked to do less, it would be easier to

Of course, if we decompose big problems into little ones, we'll add
additional complexity in the interaction of our smaller, simpler specs
(I wonder if there's a law of conservation of complexity in
specifications that's akin to the law of conservation of energy:
complexity can be neither created nor destroyed, only moved around :-).

                                        Be seeing you,

Norman.Walsh@Sun.COM   | I'm not tense, I'm just terribly, terribly
XML Standards Engineer | alert.
XML Technology Center  | 
Sun Microsystems, Inc. | 

Received on Monday, 7 January 2002 10:19:15 UTC