- From: Monica J Martin <Monica.Martin@Sun.COM>
- Date: Tue, 28 Jun 2005 12:26:15 -0700
- To: Kohei Honda <kohei@dcs.qmul.ac.uk>
- Cc: public-ws-chor@w3.org, yoshida@doc.ic.ac.uk
Kohei, A brief question (or clarification for me): see inline. > (1) Two versions of the text. > > (1-1) version 1 (without must). > > Distinct instances of a (top-level or enclosed) choreography, if > they ever run in a temporarily overlapped fashion, are not assumed > to interfere with each other in their involved communication > actions. In other words, given a choreography description, > interactions belonging to one of its instances are assumed to be > logically, hence executionally, distinguishable from those in > another. > > (1-2) version 2 (with must). > > Distinct instances of a (top-level or enclosed) choreography, if > they ever run in a temporarily overlapped fashion, must not > interfere with each other in their involved communication actions. > In other words, given a choreography description, interactions > belonging to one of its instances must be logically, hence > executionally, distinguishable from those in another. > > (2) Comments. > > Terminology: I used the term "instance". I am not sure this term > can be used for denoting a run of a top-level choreography (the > attribute name "choreographyInstanceId" seems to be used only for > enclosed choreographies). We can use the term "runs" instead of > "instances". I also used "temporarily ovelapped" instead of "in > parallel" or in "concurrent" to be concrete about what is meant. > mm1: Kohei, can you differentiate / explain why you don't use parallel or concurrent, as opposed to temporarily overlapped. And, what is the intent in what behavior we expect and wish to manage. Thanks.
Received on Tuesday, 28 June 2005 19:26:36 UTC