- From: Jon Dart <jdart@tibco.com>
- Date: Wed, 30 Jul 2003 09:55:44 -0700
- To: "Burdett David" <david.burdett@commerceone.com>
- CC: "'public-ws-chor@w3.org '" <public-ws-chor@w3.org>
Burdett, David wrote: > Jon > > Some comments in-line below. > <DB>Start and end states belong to the choreography as a whole rather than to a process within the choreography. The rules also say that states must be unique, so, according to the spec, two processes could not have the same start and end states. However parallelism is possible if two (or more) processes or interactions have a "precondition" that are the same. In this case both processes/interactions should start at the same time. Similarly, you can synchronize parallel processe/interactions by specifying a compound pre-condition such as "Process1Complete AND Process2Complete" where each state marks the completion of a process. Note that you could just have easily written, if you wanted to, "Process1Complete OR Process2Complete"</DB> I can see how this would work, but it's a pretty indirect mechanism for specifying parallelism. Maybe parallelism should be more of a first-class construct. > decision points - currently, the only indication that a process is a > decision point is that it has >1 transition out of it. Should allow > specification of decision logic? This has been discussed previously - > could be a big issue. > <DB>The current spec currently defines decisions using the > "Preconditions" element on a process or ineraction. This means that if a > process can have multiple different final states, then each state can be > separately checked for and an appropriate action taken.</DB> The spec says a precondition "contains a Boolean expression consisting of a combination of States that must be true". IMO one of the open issues is whether the preconditions should be able to encode decisions based on message contents, or on some variable set in the choreography (e.g. an iteration count). --Jon
Received on Wednesday, 30 July 2003 12:56:08 UTC