Re: Syntax Free Models

["Martin Bryan" <mtbryan@sgml.u-net.com>]

Bob
>
> Upon re-reading, the next issue that jumps out is the
> sequential process chains, for flows that are interactive
> (unless I am missing something again).
>
> Your example:
> Order > Order Response > Despatch Advice > Receipt Advice > Invoice >
Payment Advice
>
> I assume would go:
> Customer sends Order
> Supplier returns Order Response
> ...etc
>
> I understand that the sender and receiver info is conveyed
> in the accompanying Information Units, but the diagram
> syntax seems over-simplified to me.  I know you are
> trying for simple, and I agree with the goal, but it is
> visually confusing to me (for one).

There is a problem with any diagramatic methodology. The next object is your
sequence should naturally come from the customer if you are thinking in
terms of back and forth interaction, but it doesn't work like that in
practice. The sequence of sources for the above chain is:

Customer>Supplier -- Supplier>Customer -- Supplier>Customer --
Customer>Supplier -- Supplier>Cusotmer -- Customer>Supplier.

Trying to draw such chains is messy, especially when third parties get
involved in the process. Hence my simplification.

> In other words, a visual hierarchy with sequential
> levels may not be a clear representation of interactive
> events.

Interactive events are much more complex than the relatively simple
process-to-process models I have been attempting to define. In most cases
the best thing to do with interactive processes is to "build" a single
message as a set of subprocesses. A good example of how this can be done is
illustrated by OTP.

> (Aside: I think there is a sweet spot in the design space
> between too-simple and too-complex, but hitting it
> most likely requires some iteration.)

Oh too true.

Martin