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

I haven't really been following this discussion too closely, so feel free to
ignore my comments if you've already settled this issue, but ...

A stack diagram implies a layered design pattern (think OSI stack), which
indicates that the layer on top calls the layer below to further the
process. It's a runtime processing diagram. It seems to me that we're trying
to convey too much information in this stack diagram. (combining runtime
processing with other things)

The SOAP layer runs on top of the transport layer, not on top of an XML
processing layer. (which is why you need to add the strange L to the
transport layer)  At runtime, XML processing is above the SOAP message
layer. And description is not part of the runtime process. Aggregation might
be part of the runtime process, as could discovery, but I think it normally
comes at a different stage in the process. The lower levels relate to a
single message transfer process. Aggregation works at a completely different
level.

The three role diagram (provider, consumer, broker) shows the relationship
of discovery and description. I don't think these concepts belong in a stack
diagram (which normally illustrates runtime processing).

Anne

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Mario Jeckle
> Sent: Tuesday, April 08, 2003 8:04 AM
> To: Hugo Haas
> Cc: 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)
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> |I think that showing this makes the diagram confusing.
> I must confess I certainly did not my very best in fine tuning the
> diagram to be as intuitive as desirable for our WSA document.
> Therefore I repainted the middle part without changing the semantics.
>
> |I think I prefer my big background box in a different color.
> I still think having the colored box in the background may be desirable
> from the standpoint of emphasizing XML's role as base technology, but I
> think it is some kind of misleading in terms of interpreting Messaging,
> Description, and Aggregation as *part* of this base technology which is
> certainly not true and intended.
> Furthermore Security and Management both may have components which rely
> on XML, but both also deploy components which are completely independent
> of XML. This dichotomy would be hard to show ...
>
> |Hmmm... that makes showing an XML technologies box even more tricky.
> |Maybe we should just color-code the boxes on whether they are based on
> |XML or not, and use gradients where appropriate.
> Very good idea! I colored the diagram roughly (colors not not imply any
> semantics!) to make it more expressive.
> Also I integrated the influence of the underlying transport protocol to
> the messaging layer.
>
> The new diagram is attached.
>
> Cheers,
> Mario
>
> - --
> Prof. Mario Jeckle
> University of Applied Sciences Furtwangen
> Dept. Business Applications of Computer Science
>
> W3C Representative of DaimlerChrysler Research and Technology
>
> URL: http://www.jeckle.de
> MailTo:mario@jeckle.de
> MailTo:jeckle@fh-furtwangen.de
>
> My public key: http://www.jeckle.de/marioJeckle.pub
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQE+krqR46tt20EwGqwRAmtjAKDVNf+1QKGDrmJxrM3Pn1x6Z4yZ8QCgm2hd
> FNi/kFGaCMI7hPsEf/QmNp0=
> =M1+h
> -----END PGP SIGNATURE-----
>

Received on Tuesday, 8 April 2003 08:44:06 UTC