Minutes WS Choreography WG conference call 18 August 2005
See also: IRC log: http://www.w3.org/2005/08/18-ws-chor-irc
1. Attendees:
Martin, Monica, Charlton, Gary, Greg, Nick, Yves
2. Scribe
Gary
3. Agenda
To continue processing the following (starting at from Greg's comments)
http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/0020.html
4. Issues
Greg's proposed change to "once" text in 4.4:
Proposal, change to:
"once" Once means that a channel instance of this type can be used for
one interaction or can be passed to another role. When a channel
instance of this type is passed, the passer of the channel instance MUST
relinquish control, for outputting only, of that instance and passes
control to the receiver. A channel instance of this type MUST NOT be
passed to more than one receiver at any one time.
Agreed
NEW ACTION: Editors in 4.4 to update Once text as per 8/18
Greg's proposed change to "Distinct" text in 4.4:
Proposal, change to:
"Distinct" (default usage mode) Distinct means that a channel instance of this
type MAY be used multiple times by a participant within multiple interactions.
When a channel instance of this type is passed, the passer of the channel
instance MUST relinquish control, for outputting only, of that instance and
passes control to the receiver. A channel instance of this type MUST NOT be
passed by a participant to more than one receiver. In this m
Monica: question regarding passing to multiple participant
Martin: when passing, control is relinquished so cannot be passed again
Agreed
NEW ACTION: Editors in 4.4 to update Distinct text as per 8/18
Greg's proposed change to "Shared" text in 4.4:
Proposal, change to:
"Shared" Shared means that a channel instance of this type MAY be used multiple
times by multiple participants within multiple interactions. When a channel
instance of this type is passed, the participant passing the channel instance
MUST NOT reliquish control. In this mode, a participant MUST NOT specify two or
more concurrent interactions for the same channel instance with the same
operation name.
Agreed
<charlton> +1
NEW ACTION: Editors in 4.4 to update Shared text as per 8/18
Monica: primer issue to re-enforce how the distinct channel usage is used
Greg's "complete" attribute issue:
Martin: don't care if repetition, just to make sure wording is consistent
existing action (from 8/16 meeting) to global change "left to right" with "lexical ordering"
Consenus is to leave the text subject to lexical ordering rewording.
Greg's comment is on Isolation attribute:
section 5.5 isolation: change:
The following rules apply:
to:
The following rules apply to all enclosed choreographies:
Agreed
same section: change:
within an
to:
within the isolated enclosed
Agreed
change:
An isolated choreography cannot directly or indirectly perform another isolated
choreography
to:
An isolated choreography MUST NOT directly or indirectly perform another
isolated choreography
Agreed
change:
If a choreography has its isolation set to true, then any and all sub
choreographies it has are also isolated.
to: If a choreography has its isolation set to true, then any and all sub
choreographies it has MUST also be isolated.
<charlton> short comment: "...MUST also be isolated."
note sub choreo changes to enclosed choreo
<charlton> also: we've updated (as of the August 18th editor's draft) "sub
choreographies" to "enclosed choreographies"
change to:
If a choreography has its isolation attribute set to true, then any and all
enclosed choreographies MUST assume this isolation value.
agreed to above
NEW ACTION: editors in section 5.5 to fix all isolation updates from 8/18
Greg's issue on exception block naming:
Question: Since a choreography can only have 0 or 1 exception blocks,
why does exception block have a required "name" attribute
Nick: we could be selective about which name attributes are optional
Nick: at the moment all name attributes are required
Charlton: Doing the job completely is a major effort at this stage
Monica: don't know how names may be used - possibly for querying
Let's keep it
agreed to keep name attribute for exception block
SRT comments:
4.4 Channel type :
reminder of action item from 8/16 for editors to change party -> participant globally
Martin: party is the wrong term here - should be a type of a reference to
a role
change:
The element reference is used for describing the type of a party reference,
conveying the information needed to address the party being the target of an
information exchange, which is used for dynamically determining where and how to
send or receive information to or into the party. The type of a party reference
is distinguished by a Token as specified by the name attribute of the token
element within the reference element.
to:
The element reference is used for describing the type of a reference to a
participant, conveying the information needed to address the participant being
the target of an information exchange, which is used for dynamically determining
where and how to send or receive information to or into the participant. The
type of a participant reference is distinguished by a Token as specified by the
name attribute of the token element within the reference element.
also make "the element ref..." its own paragraph
Agreed
also 2nd para of 4.4
change to:
A ChannelType MUST describe the roleType and the type of participant reference,
conveying the information needed to address the participant being the target of
an information exchange, either a receiver of a request action or a sender of a
reply action, which is used for determining where and how to send or receive
information to or into the participant.
Agreed
NEW ACTION: editors change 4.4 channel types as per 8/18
5.2 Variables
add to third bullet channel capturing variable:
Charlton: also, we need to change the ';' to a ':'
How and where such information is expressed is outside the scope of this
specification.
now read:
Channel Capturing Variables. For example, a Channel Variable could
contain information such as: the URL to which the message could be sent, the
policies that are to be applied (e.g. security), whether or not reliable
messaging is to be used, etc. How and where such information is expressed is
outside the scope of this specification.
Agreed
NEW ACTION: editors update 5.2 on third bullet with text agreed 8/18
5.8 Choreography Exception Handling:
How do infrastructure/non wsdl faults get surfaced in choreo?
For example, faults from a relibility protocol such as:
http://www.oasis-open.org/apps/org/workgroup/ws-rx
Martin: we decided against defining some standards faults so maybe we are missing something.
Either have to add something or be content with wsdl faults
NEW ACTION: Charlton to look at ws-rx errors and see if/how they can
surface at wsdl and/or cdl level
5. AOB
Next call on tuesday, resume issues on this list.
Summary of Action Items from this meeting
-------------------------------------------------------------
NEW ACTION: Editors in 4.4 to update Once text as per 8/18
NEW ACTION: Editors in 4.4 to update Distinct text as per 8/18
NEW ACTION: Editors in 4.4 to update Shared text as per 8/18
NEW ACTION: editors in section 5.5 to fix all isolation updates from 8/18
NEW ACTION: editors change 4.4 channel types as per 8/18
NEW ACTION: editors update 5.2 on third bullet with text agreed 8/18
NEW ACTION: Charlton to look at ws-rx errors and see if/how they can
surface at wsdl and/or cdl level