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.