> ****g. Import
> Section 3.6:
> Monica. Perform: Structure: See previous question about collisions 
> between conditions, guards, etc. associated with a separately defined
> choreography. As well note previous question about error handling and 
> exception conditions associated with work units and influence at
> interaction level.
> David. Need to discuss.
> mm2: Started discussion last week.****
>
> **** MAY BE SUBSUMED IN IMPORT 
> 
DISCUSSION****                                                                 
                                                                             
> Other specific comments:
> Monica. Types, variables and tokens: Dual variable objects are for 
> different purposes in the abstract and portable context, correct? 
> Either specify or
> delete redundant object.
> David. I don't think I completely understand the point you are trying 
> to make.
> mm2: These are defined at the choreography definition and at the 
> interaction level. This creates a conundrum because what is the 
> master, is override allowed, and should the description and the 
> technical contract exist in the same specification. This is one of my 
> more general points.

> **** MAY BE SUBSUMED IN IMPORT 
> 
DISCUSSION****                                                                 
                                                                            
> 2) Monica. Locally defined variables: Structure: How are locally 
> defined variables defined when they are not consistent between roles that
> participate in the choreography? How are conflicts handled in the 
> global view or is alignment only if a role engages in message exchange?
> David. Basically yes. Alignment of variables can only occur as a 
> result of a message exchange. e.g. the sending of an acknowledgement will
> often allow the sender of the original message to align his state with 
> the state of the recipient. Even after alignment the variables/state 
> of each
> participant is not the same.
> mm2: Make text more explicit then and acknowledge the risk of only 
> depending on message exchange.
>  

> **** MAY BE SUBSUMED IN IMPORT 
> 
DISCUSSION****                                                                 
                                                                            
> 4) Monica. Variable combinations (Issue TVT-02: Complex evaluation 
> conditions could be made available (for algorithmic purposes) outside 
> of the
> choreography as it is not a core function. That allows the capability 
> to further modularize the language, as mathematical algorithms may have
> broader utility that only within the choreography.
> /David. Agreed. At a minimum, an evaluation condition is given a name. 
> When the choreography is performed, each name has to be
> mapped to a condition or expression consisting of multiple conditions 
> that can actually be evaluated. By "allowing" complex evaluation
> conditions in the choreography, then the choreography designer can 
> express the complex condition if he wants to or let it be evaluated 
> later.
> mm2: My point was to say that the complex conditions may not be held 
> in the choreography, but be imported for use or referenced. If agreed 
> upon, and the issue TVT-02 handled, this should be revised.