Minutes WS Choreography WG conference call 16 August 2005

IRC log: http://www.w3.org/2005/08/16-ws-chor-irc

1. Scribe.
Monica Martin 
 
2. Roll

Abbie, Charlton, Gary, Greg, Martin, Monica, Nick, Yves.

3. Agenda

http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/0019.html

plus: http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/0020.html

4. Issues from editing team

http://lists.w3.org/Archives/Member/member-ws-chor/2005Aug/0020.html

current ed copy at: http://www.w3.org/2002/ws/chor/5/07/snapshotCR.html 


Nick issue 1:
chapman: Suggest we delete party and use Participant. 
nk: We are also not consistent in case/italics on terminology as well (as 
recognized by m2 comments). 
Want to limit this item to an editorial discussion. 
chapman: See Section 2. Delete 'party', 'role', 'relationship'. 
... Action to reword first bullet point in Section 2. 

Agreed

Use capital letters only when we are talking about schema. 
nk: Define the pattern that should be used. 
Chapman: Use what is in schema. 

NEW ACTION: Martin to reword first part of Section 2 and the first bullet 
point. 

chapman: Be consistent with schema on case/italics usage. 

Nick issue 6. Semantics 
chapman: Why is this wrong? 
nk: Can I have two roleTypes with the same name at the package level? 
gb: Should the roleTypes be defined within a participantType? 
nb: Need to this to work out the participant (for role checking). 
nk: Need to specify what happens at package level. 
chapman: What about reusability? 

gb: Role type is a first class type in CDL. Section 4.1 talks about role types 
not how they are related to participants. 
... Put correct language in following section related to participants. 
<mchapman> section 4.1 change: 
<mchapman> The attribute name is used for specifying a distinct name for each 
roleType element declared within a Participant. 
<mchapman> to 
<mchapman> The attribute name is used for specifying a distinct name for each 
roleType element declared within a Package. 
<nick> Choreography Package 

Agreed

NEW ACTION: Section 4.1, para 3, Editors update as specified in the 8/16 

Nick issue 7. Semantics 

<mchapman> 4.3 change: The attribute name is used for specifying a distinct name 
for each participantType element declared within a Participant. 
<mchapman> to: 
<mchapman> The attribute name is used for specifying a distinct name for each 
participantType element declared within a Choreography Package. 

Agreed

NEW ACTION: section4.3 Editors to update as agreed at 8/16 con call

Nick issue 8. Semantics 

<mchapman> 4.4 change: 
<mchapman> <identity usage="primary"|"alternate"|"derived"|"association">
<mchapman> <token name="qname"/>
<mchapman> <identity>* 

<mchapman> to 
<mchapman> .... 
<mchapman> <token name...> + 
<mchapman> ..... 

( a + on token_name)

Agreed

NEW ACTION: Section 4.4, editors to update schema fragment and schema for token_name

Nick issue 14. Semantics 

Section 5.3.1 

gb: Does globalizedTrigger return a boolean value? 
Return boolean result of expression defined at the role where it is evaluated. 
<mchapman> The globalizedTrigger function becomes 'true' if, and only if, all 
the expressions at the different roles evaluate to 'true'. 
<mchapman> The globalizedTrigger function becomes 'true' if, and only if, all 
the expressions at the different roles evaluate to 'true'. 
<mchapman> change to: 
<mchapman> The globalizedTrigger function becomes 'true' at a role if, and only 
if, the expression evaluated at that role evaluates to 'true'. 
nk: Does evaluate at every given role?

m2: Could say 'each' for role. 
i.e. each role 
<mchapman> The globalizedTrigger function is evaluated at each role and becomes 
'true' at a role if, and only if, the expression evaluated at that role 
evaluates to 'true'. 

Agreed

NEW ACTION: Editors update to globalizedTrigger language agreed 8/16. 

Nick issue15. Semantics 
nb: Replace Type with type (i.e. Exception type) 

nk: Is exception type string? 
cb: Referring to type name; it should be a string. 
nk: This matches causeException. Shouldn't it be a qname. 
cb: It should be a qname then. 
Agreed to change string to qname in hasExceptionOccured

<mchapman> Returns "true" if an Exception of Exception Type identified by the 
parameter exceptionType has occurred. Otherwise it returns "false". 
<mchapman> change to: 
Change to: Returns "true" if an Exception identified by the parameter 
exceptionType has occurred. Otherwise it returns "false". 
<charlton> causeException is defined as a qname 


Agreed
NEW ACTION: Editors update on hasExcptionOccurred text as agreed 8/16

<charlton> see 6.2.3, Interaction Syntax 

NEW ACTION: Editors update everything to qname, ncname with lower case 

NEW ACTION: Editors update exception type to qname 

Nick issue 21:

editor's error, 1st bullet should have been a replacement for 2nd bullet

NEW ACTION: Editors delete second bullet in Section 5.8 on matching 
exceptions.

Nick issue 25. Section 6.2.3 Editorial 
chapman: Relates to change we just made. 
gb: Don't need to change because it refers to an instance of an exception. 
m2: This is related to my questions on Exceptions in general. What is level of 
reqt? 
... We should be consistent. 
chapman: This should be MAY so an exception doesn't occur every time you have a 
send/receive. 
nk: This isn't for all exchanges. 
<charlton> if we have "causeException=true" - then under an exception condition, 
an exception MUST be thrown 
chapman: Differentiate where set and used. 

chapman: When I set at design time, doesn't mean it is raised. 
gb: My understanding is different. 

chapman: Differentiate type from instance. 
nk: When you have 2 or more exceptions, this is important. 
chapman: Throwing of an exception in an interact is somewhat implicit. We don't 
declare where. 
m2: Reinforces my question on the RFC 2119 language related to exceptions. 
chapman: Where do we address this if an issue? 
<nick> When two or more record elements are specified for the same Role in an 
Interaction, with their causeException attributes set to indicate that an 
exception should be raised, then one of the Exceptions MAY occur. The throwing 
of an Exception has a non-observable predicate condition associated implicitly 
with it, that decides if an Exception occurs 
nk: We are inconsistent where we use it as a type and elswhere as a instance. 
... Applies on send/receive on exchange and for a record. 
gb: At any point with causeException, it may or may not be ignored. Spec is 
unclear as to intent. 
nk: Original intent was to be an instance. 
chapman: If this is a case, MUST in the sentence is correct. 
<nick> When two or more respond exchanges are specified there is an implicit 
choice between two or more respond exchanges 
m2: We apply this assumption to other cases? 
nk: May not have to make other changes. 
<nick> change Exchange -> exchange globally 
<nick> Variable -> variable globally 
Within the send or the receive element(s) of an exchange element, if the 
causeException attribute is set, it specifies that an exception MUST be caused 
at the respective Roles. In this case, the value of this attribute will identify 
the exception that MUST be raised. 

Agreed text above

<nick> AI to editors: change Exchange -> exchange globally 
<nick> <nick> Variable -> variable globally 
NEW ACTION: Editors to globally change exception, variable, exchange to 
lower case.

NEW ACTION: Editors update text as specified above for exceptions and 
causeException in Section 6.2.3.

Nick issue 27. Editorial Section 6.2.3 
(first 27 item!) 
m2: There is no normative language here. 
Change text to:

 When the attribute causeException is specified, in a record element, the 
corresponding Role gets into the Exception state 
When the attribute causeException is specified, in a record element, an 
exception MUST be caused at the corresponding role. 

Agreed

NEW ACTION: Editors update Section 6.2.3 for exception MUST be raised at 
corresponding role as specified above 8/16.

Nick Issue 27 (2nd one!). Editorial (item 2) Section 6.2.3 

re: When two or more record elements are specified for the same Role in an 
Interaction, with their causeException attributes set to indicate that an 
exception should be raised, then one of the Exceptions MAY occur. The throwing 
of an Exception has a non-observable predicate condition associated implicitly 
with it, that decides if an Exception occurs 
Change to: When two or more record elements are specified for the same role in 
an Interaction, with their causeException attributes set to indicate that an 
exception MUST be raised, then only one of the Exceptions MUST occur. The 
throwing of an exception has a non-observable predicate condition associated 
implicitly with it, that decides if an exception occurs. 
nk: Issue occurs when we have one interact with two exchanges that have 
causeExceptions. 
gb: At role, there will be a set of paths that occur that have record details. 
nk: How do you know what will happen? 
<mchapman> change: 
<mchapman> that decides if an Exception occurs 
<mchapman> to: 
<mchapman> that decides when ? an Exception occurs 
<mchapman> that decides what Exception occurs 

rephrase the whole sentence

<mchapman> change: 
<mchapman> The throwing of an Exception has a non-observable predicate condition 
associated implicitly with it, that decides if an Exception occurs 
<mchapman> to: 
<mchapman> The implicit decision to throw an exception is a non-observable , and 
decides what exception occurs 

Agreed

NEW ACTION: Editors update 6.2.3 with text agreed 8/16

nk: Add also that second paragraph in this section is also incorrect. 
<nick> The assign activity MAY also be used to cause an Exception at a Role, 
when the target is an Exception Variable. 
nk: An exception variable no longer exists. 
<nick> this is inconsistent with the current spec 
nk: Gary should propose. 
chapman: From an assign perspective, it is a MAY. 
<mchapman> delete: , when the target is an Exception Variable. 

Agreed

NEW ACTION: Editors update Section 6.4 to delete "when the target is an 
Exception Variable." 
re: 
When the attribute causeException is specified in a copy element, the Role 
specified by the attribute roleType gets into the Exception state after the 
assign activity has completed 
Change to: When the attribute causeException is specified in a copy element, the 
Role specified by the attribute roleType MUST enter into the exception state 
after the assign activity has completed 

Agreed

NEW ACTION: editors to globally relace "gets into the Exception state" to  "enter into the exception 
state" 

NEW ACTION: Editors update Section 6.4 to indicate MUST enter exception 
state as specified above. 


Charlton's comments 
re: "This Boolean conditional expression MUST use short circuit evaluation 
according to the XPath left to right rules." 
chapman: Go with XPath convention. 
<nick> XPath 1.0 convention 
Change to: "This Boolean conditional expression MUST use short circuit 
evaluation according to the XPath lexical rules." 

Agreed

NEW ACTION: Editors update XPath 'left to right' to 'lexical'. Global 
replace. 

Greg's comments 
Section 4.4 
Proposed language for group discussion: 
"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 
reliquishes 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. 
c/reliquishes/relinquishes 
nk: Gary or Kohei should review to ensure consistent with concepts. 
m2: Need normative language (relates to my comments). 
chapman: Happy to proposed text we should accept. Any normative language could 
be handled separately. 

Run out of time will come back to this issue.

5. AOB
Meet again  11:30 a.m.-1 p.m. PDT, Thursday, 18 August 2005. 
Yves to set up bridge

Start at Greg's comments. 

editors pen:
Barreto integrate comments as agreed. 
<charlton> Tuesday-Wednesday 
Ritzinger gets spec for Friday (19 August 2005). 
Lafon gets spec early next week 22 August 2005. 
Then to Kavantzas. 

Summary of Actions from this meeting:
-------------------------------------------------------



NEW ACTION: Martin to reword first part of Section 2 and the first bullet point.     

NEW ACTION: Section 4.1, para 3, Editors update as specified in the 8/16 

NEW ACTION: section4.3 Editors to update as agreed at 8/16 con call

NEW ACTION: Section 4.4, editors to update schema fragment and schema for token_name

NEW ACTION: Editors update to globalizedTrigger language agreed 8/16. 

NEW ACTION: Editors update on hasExcptionOccurred text as agreed 8/16

NEW ACTION: Editors update everything to qname, ncname with lower case 

NEW ACTION: Editors update exception type to qname 

NEW ACTION: Editors delete second bullet in Section 5.8 on matching 
exceptions.

NEW ACTION: Editors to globally change exception, variable, exchange to 
lower case.

NEW ACTION: Editors update text as specified above for exceptions and 
causeException in Section 6.2.3.

NEW ACTION: Editors update Section 6.2.3 for exception MUST be raised at 
corresponding role as specified above 8/16.

NEW ACTION: Editors update 6.2.3 with text agreed 8/16

NEW ACTION: Editors update Section 6.4 to delete "when the target is an 
Exception Variable."      

NEW ACTION: editors to globally relace "gets into the Exception state" to  "enter into the exception 
state" 

NEW ACTION: Editors update Section 6.4 to indicate MUST enter exception 

NEW ACTION: Editors update XPath 'left to right' to 'lexical'. Global 
replace.