Minutes WS Choreography WG conference call 23 August 2005
See also: IRC log: http://www.w3.org/2005/08/23-ws-chor-irc
1. Attendees:
Martin, Monica, Gary, Greg, Nick, Yves
2. Scribe
Martin
3. agenda:
http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/att-0029/agenda_20050823-0.txt
Agenda additions:
Martin proposal on modified text: http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/0023.html
More comments from Steve: http://lists.w3.org/Archives/Public/public-ws-chor/2005Aug/0021.html
Charlton/Monica RFC 2119 mods: http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/0031.html
amended agenda is approved
4. Approve minutes
16th August:
http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/att-0022/minutes_20050816_-_0.txt
18th August:
http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/att-0028/minutes_20050818_-_0.txt
5. Issues
current editors copy at at:
http://lists.w3.org/Archives/Member/member-ws-chor-editors/2005Aug/0040.html
Resuming issues from:
http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/0020.html
Gary's comment:
section 5.3.1 getchoreostatus
change:
. If choreoInstanceId is not specified, then there MUST only be a single
instance of that performed Choreography in the scope of the current Choreography
that is checking the status.
to:
. If choreoInstanceId is not specified, then there MUST only be a single
instance of that performed Choreography in the scope of the current Choreography
that is checking the status, otherwise a status with 'ambiguous' MUST be
returned.
agreed
ACTION: Editors to update 5.3.1 getchoreostatus with wording agreed 8/23
monicas Comment #3,
Section 1.6: Timing assuptions seems out of place here. Suggest this be placed later
around Section 5 where the CDL functions on time are specified.
Discussed whether to move section.
Agreed leave as is.
monicas comment #5 - suggested adding to primer
What can you do with roles that do not have interfaces?
ACTION: create an issue for primer to cover roles without interfaces.
monica comment #1
already agreed to use participant , done as part of last weeks revisions
monica comment 4
No solution in place if propogated excetionnot caught
<nick> A Choreography in an Enabled State completes unsuccessfully when an
Exception is caused in the Choreography and its Exception Block, if present, is
enabled. This causes the Choreography to enter the Unsuccessfully Completed
State.
change:
The unsuccessfully completed Choreography enters the Closed State once the
Exception Block, if present, is completed. If the Exception Block is not
present, the Choreography implicitly enters the Closed State and the Exception
occurred is propagated to the enclosing Choreography.
to:
The unsuccessfully completed Choreography enters the Closed State once the
Exception Block, if present, is completed. If the Exception Block is not
present, the Choreography implicitly enters the Closed State and the Exception
occurred is propagated to the enclosing Choreography, if an enclosing
choreography exists.
Agreed
ACTION: Editors to update section 5.8 with text agreed 8/23
monica issue 10
section 6.2.2
Suggest some rewriting to enable understanding:
Change from: "The /time?to?complete/ timeout, identifying
the timeframe within which an Interaction MUST complete, occurs
after the
Interaction was initiated but before it completed"
Change to: "The /time-to-complete/ timeout MUST occur after the Interaction
was initiated but before it completed. The time-to-complete attribute and the
optional timeout element are defined in Section 6.2.3. "
suggestion:
The /time-to-complete/ timeout MUST occur
after the Interaction was initiated but before it completed and the
time-to-complete has passed. The
time-to-complete attribute and the optional timeout element are defined in
Section 6.2.3.
<m2> If an Interaction has been initiated but is not completed and the
time-to-complete has been exceeded, a timeout MUST occur. ...
change:
An Interaction completes abnormally when:
to:
An Interaction MUST complete abnormally when:
Agreed
change:
·The time-to-complete timeout, identifying the timeframe within which an
Interaction MUST complete, occurs after the Interaction was initiated but before
it completed
to:
a time-to-complete timeout occurs after the interaction was initiated but
before it completed
Agreed
also change:
An Interaction completes normally when its message exchange(s) complete
successfully.
to:
An Interaction MUST complete normally when its message exchange(s) complete
successfully.
Agreed
ACTION: Editors to update section 6.2.2. with text agreed 8/23
monica issue 15
section 8.1 upcase the two MUST
ACTION: editors to upercase the musts in 8.1 as agreed 8/23
Gary noted that there is some problems with the example in 6.2.3:
http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/0015.html
Agreed to fix
ACTION: editors to fix example in 6.2.3. as agreed 8/23
Martin proposal on modified text: http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/0023.html
section 2 change 1st bullet to:
participantType, roleType, and relationshipType - Within a
Choreography, information is always exchanged between participants
within or across trust boundaries. All interactions occur between roles
being exhibited by two participants, and are constrained by a
relationship. Within WS-CDL, participants are abstractly modelled as
participantTypes, roles by roleTypes, and relationships by
relationshipTypes. A participantType groups together those parts of the
observable behavior that must be implemented by the same logical entity
or abstract organization. A logical entity or organization may be
represented by more than one participantType within a Choreography. A
RoleType enumerates potential observable behavior a participantType can
exhibit in order to collaborate with other participants. A
RelationshipType identifies the mutual commitments that must be made
between two participants for them to collaborate successfully.
nick proposed:
participantType, roleType, and relationshipType - Within a Choreography,
information is always exchanged between participants within or across trust
boundaries. All Interactions occur between roles being exhibited by two
participants, and are constrained by a relationship. Within WS-CDL, participants
are abstractly modelled as participantTypes, roles by roleTypes, and
relationships by relationshipTypes. A participantType groups together those
parts of the observable behavior that MUST be implemented by the same logical entity
or abstract organization. A logical entity or organization MAY be represented by
more than one participantType within a Choreography. A roleType enumerates
potential observable behavior a participantType MUST exhibit in order to
collaborate with other participants. A relationshipType identifies the mutual
commitments that MUST be made between two participants for them to collaborate
successfully.
Gary doesn't like the restriction that collaboration must be between two distinct participants, why restrict?
Martin says cant see the point why one would model observable behaviour between the same participant as that is an internal thing.
No decision today, people to rethink the wording.
6. AOB
Agreed to have an extra meeting on thursday 25th
2:30pm-3:30pm Eastern / 18:30-19:30 UTC/7:30 UK
7. Summary of Action Items
ACTION: Editors to update 5.3.1 getchoreostatus with wording agreed 8/23
ACTION: create an issue for primer to cover roles without interfaces.
ACTION: Editors to update section 5.8 with text agreed 8/23
ACTION: Editors to update section 6.2.2. with text agreed 8/23
ACTION: editors to upercase the musts in 8.1 as agreed 8/23
ACTION: editors to fix example in 6.2.3. as agreed 8/23