Re: working draft on architectural principles

> Roy said:
> Where does that fit in our document?  Well, for one, our document
> claims that there is one WWW architecture.  Bah humbug.  We've already
> defined two:
>
>     1) agent-level interaction with Internet protocols; and
>     2) information processing via separation of content and
>        presentation.
>
> Didier replies:
> Why we cannot consider these as two facets of a single architecture? Why
> not seeing that as principles or as constraints?

Because doing so makes it very difficult to understand the document.
Of course they can be viewed as a hundred simultaneous architectures,
just as they are in reality during system operation, but the purpose
of abstraction is to aid understanding by focusing on one level at
a time.  They both need to be defined, but not in a circular fashion,
and not in a way that obscures the important properties of one
architecture with the irrelevant details of another.

> I can understand you own definition of an architecture but there are
> others like, for instance, defining an architecture as a set of patterns
> (coming from building architecture - ref: Alexander).

Umm, no, Alexander does not define architecture as a set of patterns.
What he does is demonstrate how patterns of behavior in given settings
are made natural by desirable properties in architecture, or disrupted
by undesirable properties, thus leading to corresponding patterns and
anti-patterns for the design of spaces.  Recognizing those patterns
prior to designing such a setting should lead to better architecture.
But the first step is still to decide what it is we want to build and
what we require of that space.

> Maybe you mean that the document overlaps two level in an architectural
> hierarchy. But the separation of content from presentation is a
> constraint that can be applied to both components/agents (i.e. the
> server or the client or to any client or server proxy). It could either
> be perceived as component's internal behavior or as a structural
> constraint to be applied to components, the way processes are
> distributed and how data and processing definition are distributed
> through protocols. This leads to an other architectural view: an
> architecture can be envisioned as a set of components and constraints.
> This view leads to constraint based systems.

Yes, but if you were to look at the run-time Web and say "what is the
constraint on content versus presentation?", the answer is absolutely
no such constraint exists.  The fact of the matter is that, for the
run-time level of the Web architecture, separation of content into
tags and stylesheets is demonstrably harmful to performance. It is only
when we change the level of abstraction and look at the evolution of
systems over the course of months and years that we truly see the
benefit of separating content and presentation.

> Maybe your point is that the document should precise its architectural
> context and school of thoughts, is it that?

My point is the document should be organized and explicit in regards
to the properties desired, which may not even be universally agreed
upon at this stage, and the constraints we are imposing on the
standards in order to ensure those properties.

....Roy

Received on Friday, 30 August 2002 20:51:42 UTC