Proposal for issue 1003 - Relinquishing control of output channels

Hi

This proposal slightly changes the values associated with the ChannelType 'usage' attribute to enable it to support the three modes of linearity previously discussed by Kohei, which also implicitly defines whether channel types are relinquished when passed, and therefore addresses this issue (1003).

1) Change syntax in 2.3.4

from:
<channelType  name="ncname"
              usage="once"|"unlimited"?
              action="request-respond"|"request"|"respond"? >to: 
<channelType  name="ncname"
              usage="once"|"distinct"|"shared"?
              action="request-respond"|"request"|"respond"? >

2) Change: 
The OPTIONAL attribute usage is used to restrict the number of times a Channel of this Channel Type can be used. 

to:

The OPTIONAL attribute usage is used to constrain the way in which an instance of this Channel Type can be used. The values that can be used for this attribute are:

(1) "once"

This usage pattern indicates that a choreography can make use of a channel instance only once. This may be used in situations where single acknowledgement or callback interaction is required.

(2) "distinct" (NOTE TO GROUP: not sure of the best term for this)
 
This is the default usage pattern, which allows a channel instance to be used multiple times, but that only one participant is permitted to act as the client role for the channel instance. Therefore, if a participant passes the channel instance to another participant, then this constraint dictates that the original participant can no longer use the channel instance, as they have relinguished control over the client side of the channel instance.

(3) "shared" (NOTE TO GROUP: equivalent to the current "unlimited" value)

This usage pattern is the least constrained, as it enables more than one participant to share a reference to the client side of a channel instance. Therefore, if the original participant passes the channel instance to another participant, both the sending and receiving participants have access to the channel instance.
 



NOTE: Reason for change is:

1) To enable a choreography to indicate when a passed channel should be relinquished (i.e. solves issue 1003)

2) To provide the basis for model checking based on linearity, without having to provide a detailed technical explanation within the CDL specification. This more indepth discussion, with explanation of linearity and the associated model checking approach, will be part of a separate "supplement". The text above has been approved by Kohei and Nobuko.


Regards
Gary