RE: TAG issues brainstorming

My comments inline.  Overall, I think you and I are converging.

> -----Original Message-----
> From: www-tag-request@w3.org
> [mailto:www-tag-request@w3.org]On Behalf Of
> Roy T. Fielding
> Sent: Tuesday, December 18, 2001 3:24 PM
> To: David Orchard
> Cc: www-tag@w3.org
> Subject: 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.

So I think you are saying Yes with certain scenarios.  I think you are also
saying that statecharts should be used (question 3b).


However, I find other diagrams to be extremely useful.  Let's take a sample
case.  We say that SOAP is based upon XML.  But it's actually based upon a
subset of XML.  And SOAP is also based upon other things, like namespaces,
schema, xmlbase.  In diagramatic form it becomes very obvious that this is a
re-usable profile by vocabularies other than SOAP, say SVG or WSDL, or even
many 3rd party specifications.  Now this one example is blatant, but more
subtle examples crop up under diagram form.  I believe this technique is
very useful when describing and examining architectures, and I strongly
believe that we should have forms other than state charts.

>
> > 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.
>

I have no problem with that.  We individually do the diagrams that we think
are important, and the group decides which ones really are.

> > 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.

I think you are right that methodology isn't quite the right word.  I'm
advocating that a type of architectural description should be picked,
perhaps type of description/notations/document formats/styles would be the
better term.  I do not advocate a process for (re)designing the web - I
sincerely hope I haven't given that impression.   Once we have described in
a particular type of description/notation/format/style, then we can visit
the issue of a process for modification.
>
> > 3a. Should the methodology be an industry standard or
> created by the TAG?
>
> I don't believe that choosing an existing methodology is appropriate.

Do you mean that you disagree with a methodology (which you explained in
your previous point) or do you disagree with choosing an industry standard
architecture notation/format/style?
>
> > 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.

Awesome.  So we at least agree upon a subset of what I proposed.

>
> > 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.
>

I'm suggesting that the open issues should simply be listed textually as
issues, perhaps with a diagram or 2 associated with the issue.  For example,
if we assume that packaging is an open issue, then we could list it in an
issues section.

I think that should meet your criteria of "note conflicts".


> > 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.
>

100% agreement.  I never suggested creating a new architecture, I simply
want to describe the existing one as one of the first steps in our group.

Dave

Received on Wednesday, 19 December 2001 00:16:48 UTC