From meeting on 11-jan-05
http://lists.w3.org/Archives/Member/member-ws-chor/2005Jan/att-0002/2005-01-
11_WS-Chor_Notes.txt:

Discussion deferred as deemed to be a technical issue.

Proposal from Gary Brown:

URL: http://lists.w3.org/Archives/Public/public-ws-chor/2005May/0005.html

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

agreed in principle at the Jun/jul 05 f2f meeting:

http://www.w3.org/2002/ws/chor/5/06/F2Fminutes.html

Subsequently concrete text provided on:

http://lists.w3.org/Archives/Public/public-ws-chor/2005Jun/0020.html

and reported at meeting on 28th June:

http://lists.w3.org/Archives/Member/member-ws-chor/2005Jul/att-
0000/MeetingMinutes20050628-0.txt

editors have incorporated into sepc

changed to close confirmed as is now in the spec.