W3C home > Mailing lists > Public > public-ws-chor@w3.org > September 2004

Issue 742 - Proposal for discussion

From: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
Date: Wed, 15 Sep 2004 08:54:00 -0700
Message-ID: <41486598.44DDABB0@oracle.com>
To: public-ws-chor@w3.org

For resolving issue 742 (http://www.w3.org/Bugs/Public/show_bug.cgi?id=742) here is my
proposal:


Here are the proposed changes for section 2.4.5:

The following rules apply for a Work Unit matching:

 When a guard condition is not specified then the Work Unit always matches
 When a repetition condition is not specified then the Work Unit is not matched again
 When a guard condition or repetition condition is specified then:
o One or more variables can be specified in a guard condition or repetition condition, using XPATH and the WS-CDL functions, as described in Section 10.
o The WS-CDL function getVariable() is used in the guard or repetition condition to obtain or set the information of a variable
o When the WS-CDL function isVariableAvailable() is used in the guard or repetition condition, it means that the Work Unit that specifies the guard condition is checking if a variable is already available at a specific Role or is waiting for a variable to become available at a specific Role
o When the WS-CDL function variablesAligned() is used in the guard or repetition condition, it means that the Work Unit that specifies the guard or repetition condition is waiting for an appropriate alignment Interaction to happen between the two Roles. When the variablesAligned() WS-CDL function is used in a guard or repetition condition, then the Relationship Type within the variablesAligned() MUST be the subset of the Relationship Type that the immediate enclosing Choreography defines. In the example below, the guard condition specifies that the enclosed Work Unit is waiting for an alignment Interaction to happen between the customer Role and the retailer Role:

guard="cdl:variablesAligned(
               "PurchaseOrderAtBuyer", "PurchaseOrderAtSeller",
               "customer-retailer-relationship")”
o If variables are defined at different Roles, then they can be combined together in a guard condition or repetition condition using only the globalizedTrigger() WS-CDL function
o If variables are defined at the same Role, then they can be combined together in a guard condition or repetition condition using all available XPATH operators and the WS-CDL functions except the globalizedTrigger() WS-CDL function
o When the block attribute is set to "false", then the guard condition or repetition condition assumes that the variable information is currently available.
o If either the variable information is not available or the guard condition evaluates to "false", then the Work Unit matching fails and the Activity-Notation enclosed within the Work Unit is skipped.
o If either the variable information is not available or the repetition condition evaluates to "false", then the Work Unit is not matched again.
o When the block attribute is set to "true" and one or more variable(s) are not available, then the Work Unit MUST block waiting for the variable information to become available.
o When the variable information specified by the guard condition become available then the guard condition is evaluated. If the guard condition evaluates to "true", then the Work Unit is matched. If the guard condition evaluates to "false", then the Work Unit matching fails and the Activity-Notation enclosed within the Work Unit is skipped.
o When the variable information specified by the repetition condition become available then the repetition condition is evaluated. If the repetition condition evaluates to "true", then the Work Unit is matched again. If the repetition condition evaluates to "false", then the Work Unit is not matched again.



Here are the proposed changes for section 10:

10 WS-CDL Supplied Functions
There are several functions that the WS-CDL specification supplies as XPATH 1.0 extension functions. These functions can be used in any XPath expression as long as the types are compatible.

...
xsd:any getVariable(xsd:string varName, xsd:string documentPath?, xsd:QName  roleName?)
Returns the information of the variable with name varName as a node set containing a single node. The second parameter is optional. When the second parameter is not used, this function retrieves from the variable information the entire document. When the second parameter is used, this function retrieves from the variable information, the fragment of the document at the provided absolute location path. The third parameter is optional. When the third parameter is used that the variable information MUST be available at the Role specified by roleName. If this parameter is not used then the Role is inferred from the context that this function is used.

xsd:boolean isVariableAvailable(xsd:string varName, xsd:QName  roleName)
Returns “true” if the information of the variable with name varName is available at the Role specified by roleName. Returns “false” otherwise.

xsd:boolean variablesAligned(xsd:string varName, xsd:string withVarName,
                                               xsd:QName  relationshipName)
Returns "true" if within a Relationship specified by relationshipName the variable with name varName residing at the first Role of the Relationship has aligned its information with the variable named withVarName residing at the second Role of the Relationship.

xsd:boolean globalizedTrigger(xsd:string expression, xsd:string roleName,    xsd:string expression2, xsd:string roleName2, …)
Combines expressions that include variables that are defined at different Roles.



--
Nick
Received on Wednesday, 15 September 2004 15:54:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:05 GMT