561 2004-02-23 12:52:08 +0000 Import 2005-07-14 16:49:04 +0000 1 1 1 Unclassified WS Choreography Spec: Editorial unspecified Other other RESOLVED FIXED P2 normal -- 611 609 1 gritzinger gritzinger oldest_to_newest 1379 0 gritzinger 2004-02-23 12:52:08 +0000 > ****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. 1758 1 gritzinger 2004-04-26 10:56:31 +0000 *** Bug 617 has been marked as a duplicate of this bug. *** 1891 2 martin.chapman 2004-05-18 16:29:03 +0000 *** Bug 681 has been marked as a duplicate of this bug. *** 2415 3 martin.chapman 2004-09-30 19:18:21 +0000 xinclude has been adopted, though there are some issues to be ironed out