[Modeling] Comments on the latest Interaction Diagram specification draft.

[Marian Nodine]

This is a multi-part message in MIME format.
--------------92EA1A8D990F4AB2435C1CB7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This document is definitely making good progress! I appreciate all the
hard work that has been put into it. I have a few comments and
suggestions, however, that I would like to pass on.

In the beginning of Section 2, there is some mixing up of the terms
"agent" and "role" with respect to the lifelines. This document should
make it crystal clear what the head of those lifelines is, which is a
*role*.

On page 10, I reiterate my comment that I think the snippet box at the
top of the protocol frame is very overloaded. It contains the "sd
<protocol name>", the parameters (with no names?) and the language and
ontology variables. Could you please sort this out, and perhaps
propose some alternative to this overloading?

On page 14, with respect to role cardinalities, there is also the
issue of relative cardinalities. For example, what if you want the
participants to be "all of the UN Security Council"? What about quorum
cardinalities, such as ">50% of the committee"?.

On page 17, I reiterate that I do not like detours. They get
especially difficult if the detour involves some alternatives, as I am
not sure how to draw the lifelines in that case. Rather, I would
prefer to see the event that caused the "detour" to instead cause the
receiver to role switch to another role (e.g., "winner". Thus, for
example, in an auction there would be two alternatives in announcing
the result. The first alternative would have the seller informing the
participant that it is the winner, and the winner changing roles to
the "Winner" role, where it can do such things as arrange for
payment. The second alternative would have the seller informing the
participant that it is the loser, in which case the participant's
lifeline would stop and the interaction would end.

On page 18, I have similar issues with message cardinality that I did
with role cardinality. What about ">2/3 of the receivers"? "All of the
entities in the receiving role except for those not also in role xyz"?
I can definitely see times where this type of cardinality restriction
would be useful.

In Figure 15, what does a synchronous message mean in an agent system?
I am not questioning the notation here, just why anyone would use
one. The receiver of the message is autonomous, and can do whatever he
feels like before replying, so why should my agent even think about
waiting for it? On the notation side, now, what does figure 15 really
mean? is the "ready" the message that will unblock the wait for the
"ready for vote"? Couldn't you effectively represent the same thing by
making it a CriticalRegion? Also, how do you implement a synchronous
message to n receivers?

I have a similar problem with Figure 16. It seems like you have a
problem if access is granted, but the information never becomes
available. This is a design issue, not a notational issue,
though. There is an issue here with alternatives (it shows up in
several of your figures) as to what the semantics are for evaluating
the guards in the alternatives. Do you start with the top, and move
down? It is certainly not a good idea to assume that you will always
have a well-formed set where exactly one guard will be true in any
given circumstance. Is there such a thing as a default guard?

As a corollary to the above paragraph, Figure 19 should have guards on
the alternatives.

In the Break operation on page 27, what if the break is caused by some
external stimulus, such as a timeout or an abort operation?

There is an issue in both Figures 21 and 24, related to these nested
conversations. How do the roles in the nested interactions relate to
the roles in the outer interaction? For example, in Figure 21, the
Payment interaction may have two roles: payer and payee. How do these
map to the customer and server of the outer conversation? In Figure
24, the Interaction Overview diagram, the overview does not have a
notion of roles yet; however, they will be needed to show how the
agents progress from role to role in the interactions shown in the
overview.

By the way, I really like the notion of an interaction overview diagram.

In Figure 22, this is just a little thing, but could you show the "X"
in a sequence diagram at the end of a lifeline? This would make it
clearer.

Overall, we need to represent some things generically. Some of this
can be handled by the CombinedFragment idea. One of the issues we had
with the current FIPA protocol definitions was the representation of
generic conversational issues such as "not-understood" and
"cancel". These are different from a representational perspective. The
"not-understood" response is evoked when an agent receives a message
that it does not understand. Note that this could just terminate the
conversation, or it could provoke some sort of clarification message
exchange that allows the receiver to acquire an understanding of what
the offending message said. This can probably be handled generically
with CombinedFragments and Continuations, but I am not sure. The
"cancel", on the other hand, is sent as a result of some agent-related
event (e.g., the sender wants to send an effective control-C). I am
not sure that this type of occurrence is covered at all.

Hope this helps. Thanks again for all of the hard work!

-- Misty

--------------92EA1A8D990F4AB2435C1CB7
Content-Type: text/x-vcard; charset=us-ascii;
 name="nodine.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Marian Nodine
Content-Disposition: attachment;
 filename="nodine.vcf"

begin:vcard 
n:Nodine;Marian
tel;work:512-478-8923
x-mozilla-html:FALSE
org:Telcordia Austin Research Center
adr:;;;;;;
version:2.1
email;internet:nodine@research.telcordia.com
title:Senior Research Scientist
x-mozilla-cpt:;23928
fn:Marian Nodine
end:vcard

--------------92EA1A8D990F4AB2435C1CB7--