Web Services Choreography Description Language Version 1.0

2.2.1 Package

A WS-CDL package contains a set of one or more Choreographies andChoreography Package aggregates a set of one or more collaborationChoreography type definitions, allowingprovides a namespace for the definitions and through the various types whoseuse may be wider than a singleof XInclude [27], syntactically includes Choreography to betype definitions that are defined once. Thein other Choreography Packages.

The syntax of the package construct is:;

<package  
   name="ncname" 
   author="xsd:string"?
   version="xsd:string"
   targetNamespace="uri"
   xmlns="http://www.w3.org/2004/10/ws-chor/cdl/">
   informationType*
   token*
   tokenLocator*
   roleType*
   relationshipType*
   participantType*
   channelType*
   Choreography-Notation*
</package>

The Choreography Package contains:

• Zero or more Import definitions Zero or moreInformation Types

• Zero or more Token typesTokens and Token Locators

• Zero or more Role typesTypes

• Zero or more Relationship typesTypes

• Zero or more ParticipantsParticipant Types

• Zero or more Channel typesTypes

• Zero or more, package-levelmore Package-level Choreographies

The syntaxtop-level attributes name, author, and version define authoring properties of the package construct is:; <package name="ncname" author="xsd:string"? version="xsd:string" targetNamespace="uri" xmlns="http://www.w3.org/2004/04/ws-chor/cdl"> importDefinitions* informationType* token* tokenLocator* role* relationship* participant* channelType* Choreography-Notation* </package> The package construct allows aggregating a set ofChoreography definitions, where the elements informationType, token, tokenLocator, role, relationship, participant and channelType are shared by all the Choreographies defined within this package.document.

The targetNamespace attribute provides the namespace associated with all definitions contained in this package.Package. Choreography definitions importedincluded to this packagePackage using the inclusion mechanism, may be associated with other namespaces.

The top-level attributes author,elements informationType, token, tokenLocator, roleType, relationshipType, participantType and version, define authoring properties ofchannelType are shared by all the Choreography document.Choreographies defined within this Package.

Within a WS-CDL Package, language constructs that need to be uniquely named MUST use the attribute name for specifying a distinct name.

2.2.2 Choreography document Naming and Linking

WS-CDL documents MUST be assigned a name attribute of type NCNAME that serves as a lightweight form of documentation.

The targetNamespace attribute of type URI MUST be specified.

The URI MUST NOT be a relative URI.

A reference to a definition is made using a QName.

Each definition type has its own name scope.

Names within a name scope MUST be unique within a WS-CDL document.

The resolution of QNames in WS-CDL is similar to the resolution of QNames described by the XML Schemas specification [11].

2.2.3 Language Extensibility and Binding

If desired to extendTo support extending the WS-CDL language, this specification allows inside a WS-CDL documentthe use of extensibility elements and/or attributes defined in other XML namespaces. Extensibility elements and/or attributes MUST use an XML namespace different from that of WS-CDL. All extension namespaces used in a WS-CDL document MUST be declared.

Extensions MUST NOT change the semantics of any element or attribute from the WS-CDL namespace.

2.2.4 Semantics

Within a WS-CDL document, descriptions will be required to allow the recording of semantics definitions. The optional description sub-element is used as a textual description for documentation purposes. This element is allowed inside any WS-CDL language element.

The information provided by the description element will allow for the recording of semantics in any or all of the following ways:

• Text. This will be in plain text or possibly HTML and should be brief

• Document Reference. This will contain a URLURI to a document that more fully describes the component. For example on the top level Choreography Definition that might reference a complete paper

• Structured Attributes. This will contain machine processable definitions in languages such as RDF or OWL

Descriptions that are Texttext or Document Referencesdocument references can be defined in multiple different human readable languages.

2.3.1 RolesRole Types

A Role Type enumerates the observable behavior a participantparty exhibits in order to collaborate with other participants.parties. For example the Buyer Role Type is associated with purchasing of goods or services and the Supplier Role Type is associated with providing those goods or services for a fee.

The syntax of the roleroleType construct is:;

 <role name="ncname" ><roleType name="ncname">
   <behavior name="ncname" interface="qname"? />+
 </role></roleType>

The attribute name is used for specifying a distinct name for each roleType element declared within a Choreography Package.

Within the roleroleType element, the behavior element specifies a subset of the observable behavior a participantparty exhibits. A Role Type MUST contain one or more behavior elements.

The behavior element defines an optional interface attribute, which identifies a WSDL interface type. A behavior without an interface describes a Role Type that is not required to support a specific Web Service interface.

2.3.2 ParticipantsParticipant Types

A Participant Type identifies a set of related Roles. For example a Commercial Organization could take both a BuyerRole when purchasing goods and a Seller Role when selling them.Types that MUST be implemented by the same entity or organization. Its purpose is to group together the parts of the observable behavior that MUST be implemented by the same process.

The syntax of the participantparticipantType construct is:;

 <participant<participantType name="ncname">
   <role type="qname" />+
 </participant> 2.3.3 Relationships A</participantType>

The attribute name is used for specifying a distinct name for each participantType element declared within a Choreography Package.

An example is given below where the "SellerForBuyer" Role Type belonging to a "Buyer-Seller" Relationship Type is implemented by the association of two Roles forParticipant Type "Broker" which also implements the "SellerForShipper" Role Type belonging to a purpose."Seller-Shipper" Relationship Type:

<participantType name="Broker">
   <role type="tns:SellerForBuyer" />
   <role type="tns:SellerForShipper" />
</participantType>

2.3.3 Relationship Types

A Relationship representsType identifies the possible ways in whichRole Type and Behaviors where mutual commitments between two Roles can interact.parties MUST be made for them to collaborate successfully. For example the RelationshipsRelationship Types between a Buyer and a Seller could include:

• A "Purchasing" Relationship,Relationship Type, for the initial procurement of goods or services, and

• A "Customer Management" Relationship Type to allow the Supplier to provide service and support after the goods have been purchased or the service provided

Although RelationshipsRelationship Types are always between two Roles,Role Types, Choreographies involving more than two RolesRole Types are possible. For example if the purchase of goods involved a third-party Shipper contracted by the Supplier to deliver the Supplier's goods, then, in addition to the Purchasing and Customer Management RelationshipsRelationship Types described above, the following RelationshipsRelationship Types might exist:

• A "Logistics Provider" Relationship Type between the Supplier and the Shipper, and

• A "Goods Delivery" Relationship Type between the Buyer and the Shipper

The syntax of the relationshiprelationshipType construct is:;

 <relationship<relationshipType name="ncname">
   <role type="qname"  behavior="ncname"behavior="list of ncname"? />
   <role type="qname"  behavior="ncname"behavior="list of ncname"? />
 </relationship></relationshipType>

The attribute name is used for specifying a distinct name for each relationshipType element declared within a Choreography Package.

A relationshiprelationshipType element MUST have exactly two role typesRole Types defined.

Within the role element, the behavioroptional attribute points tobehavior identifies the commitment of a party as a list of behavior types belonging to the Role Type specified by the type withinattribute of the role typeelement. If the behavior attribute is missing then all the behaviors belonging to the Role Type specified by the type attribute of the role element.element are identified as the commitment of a party.

2.3.4 ChannelsChannel Types

A Channel realizes a point of collaboration between participantsparties by specifying where and how to exchange information.information is exchanged. Additionally, Channel information can be passed among participants.parties. This allows modeling howthe destinationmodeling of messages is determined, staticallyboth static and dynamically,dynamic message destinations when collaborating within a Choreography. For example, a Buyer could specify Channel information to be used for sending delivery information. The Buyer could then send the Channel information to the Seller who then forwards it to the Shipper. The Shipper could then send delivery information directly to the Buyer using the Channel information originally supplied by the Buyer.

A Channel Type MUST describe the Role Type and the type of a Web Servicereference type of a participant,party, being the target of an Interaction, which is then used for determining where and how to send/receive information to/into the participant.party.

A Channel Type MAY specify the instance identity of a business processan entity implementing the behaviorbehavior(s) of a participant,party, being the target of an Interaction.

A Channel Type MAY describe one or more logical conversations between participants,parties, where each conversation groups a set of related message exchanges.

One or more Channel(s) MAY be passed around from one Role to another. A Channel Type MAY restrict the types of Channel(s)Channel Type(s) allowed to be exchanged between the Web Services participants,parties, through a Channel of this Channel.Channel Type. Additionally, a Channel Type MAY restrict its usage by specifyingthe number of times a Channel can beof this Channel Type is used.

The syntax of the channelType construct is:;

<channelType  name="ncname"
    usage="once"|"unlimited"?
    action="request-respond"|"request"|"respond"? >
  <passing  channel="qname"
        action="request-respond"|"request"|"respond"?
         new="true"|"false"?new="xsd:boolean"? />*
  <role  type="qname"  behavior="ncname"? />
  <reference>
     <token  type="qname"/>+type="qname"/>
  </reference>
  <identity>
     <token  type="qname"/>+
   </identity>*</identity>?
</channelType>

The attribute name is used for specifying a distinct name for each channelType element declared within a Choreography Package.

The optional attribute usage is used to restrict the number of times a Channel can be used.

The optional element passing restrictsdescribes the Channel(s) allowed to beChannel Type(s) that are exchanged from one Role Type to another Role,Role Type, when using a Channel of this Channel Type in an Interaction. In the case where the operation used to exchange the Channel is of request-response type, then the attribute action within the passing element defines if the Channel will be exchanged during the request or during the response. The Channels exchanged canMAY be used in subsequent Interaction activities. If the element passing is missing then this Channel canType MAY be used for exchanging business documents and all types of ChannelsChannel Types without any restrictions.

The element role is used to identify the Role Type of a participant,party, being the target of an Interaction, which is then used for statically determining where and how to send/receivesend or receive information to/intoto or into the participant.party.

The element reference is used for identifyingdescribing the WSDL servicereference type of a participant,party, being the target of an Interaction, which is then used for dynamically determining where and how to send/receivesend or receive information to/intoto or into the participant.party. The service reference of a participantparty is distinguished by a set ofToken typesas specified by the token element within the reference element.

The optional element identity MAY be used for identifying an instance of a business processan entity implementing the behavior of a participantparty and for identifying a logical conversation between participants.parties. The businessprocess identity and the different conversations are distinguished by a set of Token typesTokens as specified by the token element within the identity element.

The following rule applies for Channel Type:

• If two or more Channel Types SHOULD point to Role Types that MUST be implemented by the same entity or organization, then the specified Role Types MUST belong to the same Participant Type. In addition the identity elements within the Channel Types MUST have the same number of Tokens with the same informationTypes specified in the same order

The example below shows the declarationdefinition of the Channel typeType RetailerChannel. The Channel Type identifies the Role type tns:Retailer.Type as the "tns:Retailer". The address of the Channel is specified in the reference element, whereas the businessprocess instance can be identified using the identity element.element for correlation purposes. The passing element allows only a Channel instance of the ConsumerChannel Type to be sent over the RetailerChannel.;RetailerChannel Type.;

<channelType name="RetailerChannel">
  <passing channel="ConsumerChannel" action="request" />
  <role type="tns:Retailer" behavior="retailerForConsumer"/>
  <reference>
    <token type="tns:retailerRef"/>
  </reference>
  <identity>
    <token type="tns:purchaseOrderID"/>
  </identity>
</channelType>

2.4.1 Information Types

Information types describe the type of information used within a Choreography. By introducing this abstraction, a Choreography definition avoids referencing directly the data types, as defined within a WSDL document or an XML Schema document.

The syntax of the informationType construct is:;

<informationType name="ncname";                 type="qname"? | element="qname"? />

The attribute name is used for specifying a distinct name for each informationType element declared within a Choreography Package.

The attributes type, and element describe the document to be an XML Schema type, or an XML Schema element respectively. The document is of one of these types exclusively.

2.4.2 Variables

Variables capture information about objects in a Choreography as defined by the Variable Usagetheir usage:

• Information Exchange Capturing Variables that, which contain information such as an Order that is used to:to

  • Populate the content of a message to be sent, or

  • Populated as a result of a message received

• State Variables thatCapturing Variables, which contain observableinformation about the Stateobservable changes of a Role as a result of information being exchanged. For example: Whenexample when a Buyer sends an orderOrder to a Seller, the Buyer could have a StateVariable called "OrderState" set to a value of "OrderSent" and once the message was received by the Seller, the Seller could have an Statea Variable called "OrderState" set to a value of "OrderReceived". Note that the variableVariable "OrderState" at the Buyer is a different variableVariable to the "OrderState" at the Seller

• Once an order is received, then it might be validated and checked for acceptability in other ways that affect how the Choreography is performed. This could require additional states to be defined for "Order State", such as: "OrderError", which means an error was detected that stops processing of the message, "OrderAccepted", which means that there were no problems with the Order and it can be processed, and "OrderRejected", which means, although there were no errors, it cannot be processed, e.g. because a credit check failedChannel Capturing Variables. For example, a Channel Variable could contain information such as the URL to which the message shouldcould be sent, the policies that are to be applied, such as security, whether or not reliable messaging is to be used, etc.

The value of Variables:

• Is available to all theRoles by initializing them prior to the start ofwithin a Choreography CommonChoreography, when the Variables thatcontain information that is common knowledge to two or more Roles, e.g.knowledge. For example the Variable "OrderResponseTime" which is the time in hours in which a response to an Order must be sent is initialized prior to the initiation of a Choreography and can be used by all Roles within the Choreography

• Can be made available as a result of an Interaction

  • Information Exchange Capturing Variables are populated and become available at the Roles in the ends of an Interaction

  • State Capturing Variables, that contain information about the observable information changes of a Role by populating themas a result of an Interactioninformation being exchanged, are recorded and become available

• Can be created or changed and made available locally at a Role by assigning data from other information Locally Defined Variables that contain information created and changed locally by a Role.information. They can be Information Exchange, State or Channel Variables as well as variables of other types.Capturing Variables. For example "Maximum Order Amount" could be data created by a sellerSeller that is used together with an actual order amount from an Order received to control the ordering of the Choreography. In this case how Maximum"Maximum Order AmountAmount" is calculated and its value would not be known by the other Roles

• Can be used to determine the decisions and actions to be taken within a Choreography

The variableDefinitions construct is used for declaringdefining one or more variablesVariables within a Choreography block.

The syntax of the variableDefinitions construct is:;

<variableDefinitions>
   <variable   name="ncname"
       informationType="qname"|channelType="qname"
       mutable="true|false"?
       free="true|false"?
        silent-action="true|false"? role="qname"?silentAction="true|false"?
       roleType="qname"? />+
</variableDefinitions>

The declared variablesdefined Variables can be of the following types:

• Information Exchange Capturing Variables, State Capturing Variables. The attribute informationType describes the type of the variableobject captured by the Variable

• Channel Capturing Variables. The attribute channelType describes the type of the Channelchannel object captured by the Variable

The optional attribute mutable, when set to "false" describes that the variableVariable information when initialized, cannot change anymore. The optionaldefault value for this attribute is "true".

The optional attribute free, when set to "true" describes that a variable declaredVariable defined in an enclosing Choreography is also used in this Choreography, thus sharing the variableVariables information. When the attribute free is set to "true", the variableThe following rules apply in this case:

• The type of a free Variable MUST match the type of the variable declaredVariable defined in thean enclosing Choreography.Choreography

• A perform activity MUST bind a free Variable defined in an enclosed Choreography with a Variable defined in an enclosing Choreography when sharing the Variables information

The optional attribute free, when set to "false" describes that a variableVariable is declareddefined in this Choreography.

WhenThe default value for the attributefree attribute is set to "false", the variable resolves to the closest enclosing Choreography, regardless of the type of the variable."false".

The optional attribute silent-action,silentAction, when set to "true" describes that activitiesthere SHOULD NOT be any activity used for makingcreating or changing this variable available MUST NOT be presentVariable in the Choreography.Choreography, if these operations should not be observable to other parties. The default value for this attribute is "false".

The optional attribute roleroleType is used to specify the locationRole Type of a party at which the variableVariable information will reside.

The following rules apply to Variable Declarations: IfDefinitions:

• The attribute name is used for specifying a distinct name for each variable iselement declared within a variableDefinitions element when needed. The Variables with Role Type not specified MUST have distinct names. The Variables with Role Type specified MUST have distinct names, when their Role Type is the same

• A Variable defined without a Role, itRole Type is impliedequivalent to a Variable that itis declareddefined at all the RolesRole Types that are part of the RelationshipsRelationship Types of the Choreography.Choreography where the Variable is defined. For example if Choreography C1 has Relationship Type R that has a tuple (Role1, Role2), then a variableVariable x defined in ChreographyChoreography C1 without a RoleroleType attribute means it is declareddefined at Role1 and Role2

2.4.3 Tokens

A Token is an alias for a piece of data in a variableVariable or message that needs to be used by a Choreography. Tokens differ from Variables in that Variables contain values whereas Tokens contain information that defines the piece of the data that is relevant. For example a Token for "Order Amount" within an Order businessXML document could be an alias for an expression that pointed to the Order Amount element within anthe Order XML document. This could then be used as part of a condition that controls the ordering of a Choreography, for example "Order Amount > $1000".

All Tokens MUST have a type,an informationType, for example, an Order Amount"Order Amount" would be of type amount, Order Id"amount", "Order Id" could be alphanumeric and a counter an integer.

Tokens types reference a document fragment within a Choreography definition and Token Locators provide a query mechanism to select them. By introducing these abstractions, a Choreography definition avoids depending on specific message parts,types, as described by WSDL, or a specific query string, as specified by XPATH, but instead the parts orthe query string can change without affecting the Choreography definition.

The syntax of the token construct is:;

<token  name="ncname"  informationType="qname" />

The attribute name is used for specifying a distinct name for each token element declared within a Choreography Package.

The attribute informationType identifies the type of the document fragment.

The syntax of the tokenLocator construct is:;

<tokenLocator  tokenName="qname" 
      informationType="qname" 
      query="XPath-expression"? />

The attribute tokenName identifies the name of the token typeToken that the document fragment locator is associated with.

The attribute informationType identifies the type on which the query is performed to locate the token.Token.

The attribute query defines the query string that is used to select a document fragment within a document.

The example below shows that the token purchaseOrderIDToken "purchaseOrderID" is of type xsd:int. The two tokenLocators show how to access this token in "purchaseOrder" and "purchaseOrderAck" messages.;

<token name="purchaseOrderID" informationType="xsd:int"/>
<tokenLocator tokenName="tns:purchaseOrderID" informationType="purchaseOrder"       
                 part="PO"query="/PO/OrderId"/>
<tokenLocator tokenName="tns:purchaseOrderID" informationType="purchaseOrderAck" 
                 part="POAck"query="/POAck/OrderId"/>

2.4.4 Choreographies

A WS-CDL document explicitly prescribes the rules, agreed between Web Service participants, that govern the ordering of exhanged messages and the provisioning of alternative patterns of behavior.. The operational semantics of these rules are based on the information-driven computational model, where availability of variable information causes a guarded unit-of-work and its enclosed actions to be enabled.

A Choreography allows constructing global compositions of Web Service participants by explicitly asserting theirChoreography. defines re-usable the common rules, that govern the ordering of exhanged messages and complementary observable behaviors.the provisioning patterns of collaborative behavior, agreed between two or more interacting peer-to-peer parties

A Choreography declareddefined at the packagePackage level is called a top-level Choreography, and does not share its context with other top-level Choreographies. A Choreography performed within another Choreography is called an enclosed Choreography. APackage MUSTMAY contain exactly one top-level Choreography, that is explicitlymarked explicitly as the root Choreography.

The rootA Choreography isdefines the only top-level Choreographyre-usable the common rules, that govern the ordering of exhanged messages and the provisioning patterns of behavior, as the action(s) performing the actual work, such as exchange of messages, when the specified ordering constraints are satisfied.

The re-usable behavior encapsulated within a Choreography MAY be initiated.performed within an enclosing Choreography, thus facilitating recursive composition. The rootperformed Choreography is enabled when itthen called an enclosed Choreography.

The Choreography that is initiated. All non-root, top-level Choreographiesperformed MAY be enabled when performed. Adefined either:

• Locally - they are contained, in the same Choreography facilitates recursive composition, where combining two or more Choreographies can form a new enclosingdefinition as the Choreography that may be re-usedperformed them

• Globally - they are specified in different contexts. Aa separate top-level Choreography definition that is defined in the same or in a different Choreography Package and can be used by other Choreographies and hence the contract is reusable

A Choreography MUST contain at least one Relationship type,Type, enumerating the observable behavior this Choreography requires its participantsparties to exhibit. One or more RelationshipsRelationship Types MAY be defined within a Choreography, modeling multi-participantmulti-party collaborations.

A Choreography acts as a lexical name scoping context as it restricts the visibility of variable information.for Variables. A variableVariable defined in a Choreography is visible for use in this Choreography and all its enclosed Choreographies,Choreographies up-to the point that the Variable is re-defined as an non-free Variable, thus forming a Choreography Visibility Horizon for this Variable.

A Choreography MUST containsMAY contain one or more Choreography definitions that MAY be performed only locally within this Choreography.

A Choreography MUST contain an Activity-Notation. The Activity-Notation specifies the enclosed actions of the Choreography that perform the actual work.

A Choreography can recover from exceptional conditions and provide finalization actions by defining:

• One Exception block, which MAY be defined as part of the Choreography to recover from exceptional conditions that can occur in that enclosing Choreography

• One Finalizer block, which MAY be defined as part of the Choreography to provide the finalization actions for that enclosing Choreography

The Choreography-Notation is used to define a root or a top-levelChoreography. The syntax is:;

<choreography  name="ncname"
      complete="xsd:boolean XPath-expression"?
       isolation="dirty-write"| "dirty-read"|"serializable"?isolation="dirty-write"|"dirty-read"|"serializable"?
      root="true"|"false"? >
   <relationship  type="qname" />+
   variableDefinitions?
   Choreography-Notation*
      Activity-Notation
   <exception  name="ncname">
        WorkUnit-Notation+
   </exception>?
   <finalizer  name="ncname">
        WorkUnit-Notation
   </finalizer>?
</choreography>

The attribute name is used for specifying a distinct name for each choreography element declared within a Choreography Package.

The optional complete attribute allows to explicitly complete a Choreography as described below in the Choreography Life-line section.

The optional isolation attribute specifies when a variableVariable information that is declareddefined in an enclosingenclosing, and changed within an enclosed Choreography is visibleavailable to its enclosing andsibling Choreographies:

• When isolation is set to "dirty-write", the variableVariable information canMAY be immediately overwritten by actions in other Choreographies

• When isolation is set to "dirty-read", the variableVariable information isMAY be immediately visible for read but not for write to other Choreographies

• When isolation is set to "serializable", the variableVariable information isMUST be visible for read or for write to other Choreographies only after this Choreography has ended successfully

The relationship element within the choreography element enumerates the Relationships this Choreography MAY participate in.

The optional variableDefinitions element declaresenumerates the variables that are visibleVariables defined in this Choreography and all its enclosed Choreographies and activities.Choreography.

The optional root element marks a top-level Choreography as the root Choreography of a package.Choreography Package.

The optional Choreography-Notation within the choreography element declaresdefines the Choreographies that MAY be performed only within this Choreography.

The optional exception element defines the Exception block of a Choreography by specifying one or more Exception Work Unit(s).

The optional finalizer element defines the Finalizer block of a Choreography by specifying one Finalizer Work Unit.

2.4.5 WorkUnits

A Work Unit prescribes the constraints that must be fulfilled for making progress and thus performing actual work within a Choreography. Examples of a Work Unit include:

• A Send PO Work Unit that includes Interactions for the Buyer to send an Order, the Supplier to acknowledge the order, and then later accept (or reject) the order.Order. This work unitWork Unit would probably not have a Guardguard condition

• An Order Delivery Error Work Unit that is performed whenever the Place Order Work Unit did not reach a "normal" conclusion. This would have a Guardguard condition that identifies the error, see also Choreography Exceptions and Transactionserror

• A Change Order Work Unit that can be performed whenever an order acknowledgement message has been received and an order rejection has not been received

A Work Unit canMAY prescribe the explicit rules for enforcing theconstraints that preserve the consistency of the collaborations commonly performed between the Web Service participants.parties. Using a Work Unit an application canMAY recover from faults that are the result fromof abnormal actions and also MAY finalize completed actions that need to be logically rolled back.

AWhen enabled, a Work Unit specifies the data dependencies that must be satisfied before enabling one or more enclosed actions. These dependencies expressexpresses interest(s) on the availability of variableone or more Variable information that already existsexist or will be created in the future.

The Work UnitsUnit's interest(s) are matched when all the required, one or more variablerequired Variable information are or become available.available and the specified matching condition on the Variable information is met. Availability of some variableVariable information does not mean that a Work Unit matches immediately. Only when all variableVariable information required by a Work Unit become available, in the appropriate Visibility Horizon, does matching succeed. Variable information available within a Choreography MAY be matched with a Work Unit that will be enabled in the future. One or more Work Units MAY be matched concurrently if their respective interests are matched. When the matching succeeds thea Work Unit ismatching succeeds then its enclosed actions are enabled.

A Work Unit MUST contain an Activity-Notation , which is enabled when its enclosing Work Unit is enabled.that performs the actual work.

A Work Unit completes successfully when all its enclosed actions complete successfully.

A Work Unit that completes successfully MUST be considered again for matching (based on its Guardguard condition), if its repetition condition evaluates to "true".

The WorkUnit-Notation is defined as follows:;

<workunit  name="ncname"
      guard="xsd:boolean XPath-expression"?                 
      repeat="xsd:boolean XPath-expression"? 
       block="true|false"block="true|false"? >
      Activity-Notation
</workunit>

The Activity-Notation specifies the enclosed actions of a Work Unit.

The guard condition of a Work Unit, specified by the optional guard attributeattribute, describes the reactiveinterest on the availability of one or more, existing or future variable information and its usage is explained in section 2.4.5.1.Variable infor