RE: TAG issues brainstorming

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)?
2. Assuming yes to #1, what kinds of facets should be described?
3. Based upon facets to be described, what methodology should be used to
describe them?
3a. Should the methodology be an industry standard or created by the TAG?
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
4. Should the SAD document open issues - like URI versus URI-Ref data-types,
packaging, profiles, etc.?
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

Cheers,
Dave


> -----Original Message-----
> From: www-tag-request@w3.org
> [mailto:www-tag-request@w3.org]On Behalf Of
> Roy T. Fielding
> Sent: Monday, December 17, 2001 9:16 PM
> To: David Orchard
> Cc: www-tag@w3.org
> Subject: Re: TAG issues brainstorming
>
>
> On Mon, Dec 17, 2001 at 08:12:53PM -0800, David Orchard wrote:
> > Issues:
> >
> > 1. System architecture document.  We should describe the way the web
> > currently works, leveraging Tim's dependency diagram.  This
> should also help
> > with MB's issue that he doesn't believe HTTP is well enough
> understood.
> > Rational has a leading methodology for software
> architecture, described in
> > http://www.rational.com/products/whitepapers/350.jsp.  If
> we chose this
> > methodology, I don't think we need to go into all the
> views.  A logical
> > view - showing dependencies (uses relationships) - plus a
> physical view
> > would be a good start.  I'm very open to other
> methodologies as well, I
> > simply list this one as an industry standard.  This
> document would also list
> > open issues, such as my issues #2-#5.  I suggest that we
> adopt a methodology
> > from industry rather than creating our own.
>
> That methodology is based on object-oriented design, which is not an
> appropriate paradigm for the Web.  It would be like using
> railroad definitions
> to describe an airport (or vice versa).  They mention the
> notion of using
> E-R diagrams as a substitution for the logical view, but I've
> never seen
> someone use 4+1 outside of OOD.  A data-flow methodology like
> JSD would
> fit better, but few people know how to use (or read) JSD.
>
> I did not restrict the descriptions in my dissertation [1] to
> any particular
> methodology, but they were more for the sake of examples than
> a rigorous
> topology of all aspects of the Web.
>
>   [1] http://www.ebuilt.com/fielding/pubs/dissertation/top.htm
>
> That description of the Web architecture is my interpretation of Tim's
> original design goals, plus the the ones we added in 1994-95.
>  If we are
> going to make a more formal definition, then we are going to have to
> decide what the Web is first and come to some sort of agreement on the
> terminology surrounding URI, resources, representations,
> metadata, etc.
>
> Of course, I prefer my definitions. ;-)
>
> Cheers,
>
> Roy T. Fielding, Chief Scientist, eBuilt
>                  (fielding@ebuilt.com)
<http://www.ebuilt.com/fielding/>

                 Chairman, The Apache Software Foundation
                 (fielding@apache.org)  <http://www.apache.org/>

Received on Tuesday, 18 December 2001 17:33:55 UTC