RE: The stack diagram (was RE: Discussion topic for tomorrow's call)

I am actually ok with George's diagram (it's actually closer to the original than Mario's, but I sent my comment on Mario's before studying George's -- apologies for that).  Except for some minor changes:

"services" -> "description"

And I would remove the XML from each of the boxes, and either represent it as a backplane or add a note the diagram explaining that all the artifacts are XML.

Eric

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Wednesday, April 09, 2003 3:51 PM
To: Hugo Haas; Newcomer, Eric
Cc: Jeckle, Mario; Champion, Mike; www-ws-arch@w3.org;
Savas.Parastatidis@newcastle.ac.uk; RogerCutler@chevrontexaco.com
Subject: RE: The stack diagram (was RE: Discussion topic for tomorrow's
call)


So why don't we keep the diagram at a more conceptual level and not talk
about specific technologies, per George's suggestion:

Four boxes, two pillars:

  S    M
  E    A          Processes
  C    N  --------------------------
  U    A          Services
  R    G  --------------------------
  I    E          Messages
  T    M  --------------------------
  Y    T          Transports




> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Hugo Haas
> Sent: Wednesday, April 09, 2003 12:26 PM
> To: Newcomer, Eric
> Cc: Jeckle, Mario; Champion, Mike; www-ws-arch@w3.org;
> Savas.Parastatidis@newcastle.ac.uk; RogerCutler@chevrontexaco.com
> Subject: Re: The stack diagram (was RE: Discussion topic for tomorrow's
> call)
>
>
>
> * Newcomer, Eric <Eric.Newcomer@iona.com> [2003-04-09 11:08-0400]
> > This would be much clearer and more useful without the protocol
> binding box extending into the SOAP area.  Representing the major
> concepts clearly in a diagram should be the goal rather than
> including every detail in the diagram.
> >
> > We want to provide someone with a visual understanding of the
> architectural framework, meaning primarily what is included
> within it, and represent *to some extent* the relationships among
> the major pieces.
> >
> > Drawing the line between what is clear and general and specific
> and confusing is never easy, and no doubt we will have many opinions.
> >
> > I'd like to propose that we adopt this version of the diagram,
> without the protocol binding part, and move on.
>
> I think that it all comes down to knowing how many diagrams we need to
> represent our space, so that each diagram is reasonnably simple and
> understandable.
>
> We need to address the fact that HTTP without SOAP may be used to do
> some requests, such as with the SOAP 1.2 HTTP GET binding.
>
> This is why I am worried about showing HTTP in the transport box
> without any link to the message box. I think that I could live with
> this diagram if there was some text accompanying it talking about
> that.
>
> And in this case we should also add some explanation about why HTTP is
> in a box called transport, otherwise I foresee comments about that.
>
> Regards,
>
> Hugo
>
> --
> Hugo Haas - W3C
> mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
>

Received on Wednesday, 9 April 2003 16:48:46 UTC