Fw: Last Call Issue: WORKUNIT GUARD CONDITION SEMANTICS

----- Original Message ----- 
From: Gary Brown 
To: public-ws-chor@w3.org 
Sent: Wednesday, January 05, 2005 2:18 PM
Subject: Last Call Issue: WORKUNIT GUARD CONDITION SEMANTICS


Currently if guard evaluates to false, when block=true, it will continue to block until the guard evaluates to true

Although I can see that having the ability to block until a condition (e.g. OrderValue > 3000) is true is useful - I believe this will make it harder to infer flow from a CDL document, as the determination of dependencies between different concurrent threads now becomes more complex, as the actual nature of the execution of a choreography will be dependent upon runtime variable values. 

In the most extreme case, you could imagine a choreography having a single <parallel> construct with 'n' workunits, all having defined blocking conditions, where the flow is determined only by inferring the potential links between the cause and effect of activities within the workunits, that may change values that would then cause other workunits to become enabled. Although this is not the most likely usage of CDL, the fact that we provide mechanisms that support this usage means that we also have to provide model checking to support this - and I think such uses would lead to a state explosion of possible outcomes, which would go against the stated aim of making model checking easy. 

I believe the "block until" mechanism is a good implementation technique for building event based systems - however CDL is a description language, and I don't think this approach is useful for building a good description of the interactions between distributed participants.

Regards
Gary and Steve