Re: TAG issues brainstorming

On Tue, Dec 18, 2001 at 02:30:50PM -0800, David Orchard wrote:
> I'm not sure what you are suggesting or agree/disagree with.  Some questions
> that seem appropriate:
> 1. Should the TAG create a system architecture document (SAD)?

Yes and no.  The Web is too big to be described as a complete system.
The best we can do is define scenarios and then views of the participating
components during those scenarios, but I have found that those types of
diagrams are useless for describing what is actually relevant to the
architecture: the contraints on the interfaces between components that
allows them to behave independently and interoperably.  Statecharts
are better for that level of description.

> 2. Assuming yes to #1, what kinds of facets should be described?

How about if we just try to describe them all and then choose which ones
are useful?  That would let us do more work in parallel.

> 3. Based upon facets to be described, what methodology should be used to
> describe them?

I think "methodology" is confusing the issue.  There are types of
architectural description and there are methodologies for the design of
architectures.  If we follow a standard methodology to design the Web,
then the description we come up with will not match the Web architecture,
because the Web was not designed using one of the standard methodologies
in the first place.

> 3a. Should the methodology be an industry standard or created by the TAG?

I don't believe that choosing an existing methodology is appropriate.

> 3b. If an entire methodology is not usable, are there portions of existing
> methodologies that are re-usable, like Use cases done as part of the 4+1
> methodology

Yes, definitely.  I suggest that we find a way to divide up the space,
perhaps using a small set of scenarios, and then use various architectural
descriptions to portray the architecture during those scenarios.

> 4. Should the SAD document open issues - like URI versus URI-Ref data-types,
> packaging, profiles, etc.?

I think we should note conflicts between desired and actual architecture,
but only try to represent the desired one.

> 5. What existing works should the SAD incorporate?
> 
> I think that you are answering:
> 1. yes
> 2. processes (or data flow) and definitions (from your thesis I see these 2
> views)
> 3. Roy Fielding notation (tm? ;-)
> 5. TimBL design goals, Roy Fielding thesis
> 
> I'm certainly not against re-use of existing materials and tools.  In fact,
> my rationale for using an industry standard methodology is so that we won't
> have to train people on the notations and won't have to create diagramming
> tools.  I also expressly want to re-use what material exists, like Tim's
> design goals and dependency diagrams

Okay with me.  I just don't want to start creating a new architecture in the
name of describing the existing one.

....Roy

Received on Tuesday, 18 December 2001 18:26:26 UTC