Minutes WS Choreography WG conference call 17 May 2005
IRC: http://www.w3.org/2005/05/17-ws-chor-irc
Agenda:
http://lists.w3.org/Archives/Public/public-ws-chor/2005May/att-0043/Agenda-05172005-0.txt
1. Role Call
------------
Tony, Abbie, Greg, Martin, Nick, Steve, Yves, Charlton, Gary
2. Confirm scribe
-----------------
Greg
3. Agenda Changes
-----------------
4. Approve minutes
------------------
10th May 2005
http://www.w3.org/2002/ws/chor/5/05/MeetingMinutes20050510-0.txt
*** APPROVED
5. Action item review
---------------------
1. ACTION: Martin to do UML diagram from scratch for CDL
IN PROGRESS
Status: No change.
2. ACTION: SRT Check 1027 for issues pertaining to identity
DONE - no issues pertaing to identity
3. ACTION: Add text in primer or spec to clarify participant relationship/role pertaining to issue 1027
DONE
4. ACTION: Chairs to talk with the XPath 2.0 WG to determine the direction of three-valued logic and existential qualifiers
DONE
5. ACTION: SRT to create a new issue about accessory pertaining to issue 1128. SRT to investigate
DONE
Status: No change.
6. ACTION: chairs to respond to issue raiser for closed issues
STANDING ITEM
7. ACTION: Steve to learn about this issue from Nick for the Primer (issue 1079)
DONE - Noew a primer issue
8. ACTION: Yves to define what is meant by correctness
IN PROGRESS - Yves to put text on mailing list this week.
9. ACTION: SRT to close issue 1002 and take action to add 1002-addressing
DONE
10. ACTION: Charlton, Gary and Nick to discuss 1008 off line to resolve (leaving 1008 on the agenda)
DONE
11. ACTION: Close 971 as Resolved, won't fix
DONE
12. ACTION: Record 996 as resolved fixed with text in minutes (12 apr)
DONE
13. ACTION: Record 998 as resolved won't fix
DONE
14. ACTION: Record 1018 as resolved fixed
DONE
15. ACTION: Record 1055 as RESOLVED LATER so is editorial
DONE
16. ACTION: Record 1079 as CLOSE WON'T FIX
DONE
17. ACTION: SRT - Put in text related to access and modify in the primer.
DONE
18. ACTION: SRT - Insert 1028 text provided by GBrown into Issue 1128.
DONE
19. ACTION: MC - Close 1110 with the proposed resolution.
IN PROGRESS
Status: No change.
20. ACTION: Martin to record issue 1102 as resolved/later.
IN PROGRESS
Status: No change.
21. NEW ACTION (augments 21 above): Fletcher to complete approved approach for #21.
Status: No change
22. ACTION: Steve to close 1128 as resolved will not fix, but add text to the primer about
the use of lists and arrays in CDL.
DONE
23. ACTION: Steve and/or Martin to generate a list of the issue numbers that the editing team
should be working on as a spot check.
IN PROGRESS
Status: No change.
24. ACTION: Chairs discuss and provide a recommendation.
Status: No change.
25. ACTION: Kavantzas provide example showing how WS-CDL binds to faults in WSDL1.1 and WSDL1.2 to show the benefit of his approach.
Status: No change.
6. Proposals
------------
1008 http://www.w3.org/Bugs/Public/show_bug.cgi?id=1008
Summary: FAULT HANDLING
URL: http://lists.w3.org/Archives/Public/public-ws-chor-comments/2005Jan/0012.html
Lastest thread: http://lists.w3.org/Archives/Public/public-ws-chor/2005May/0058.html
PROPOSAL: http://lists.w3.org/Archives/Public/public-ws-chor/2005May/0049.html
REMAIN OPEN
As of last week, there was some confusion about what Nick was saying, Nick supplied example in today's agenda
http://www.w3.org/Bugs/Public/show_bug.cgi?id=1008
Nick: The current spec defines WSDL1.1 faults using the InformationType to
Nick: relate to the appropriate WSDL Message Type. However, if an operation
Nick: has multiple faults, each with the same Message Type, then the only
Nick: thing that distinguishes them is the fault name.
Nick: However, the 'interaction' syntax does not support specifying a name
Nick: associated with the "respond" exchange, when it is receiving a fault -
Nick: it only specifies the Information Type, which in turn only links to the
Nick: For consistency across WSDL1.1 and WSDL2, perhaps the InformationType
Nick: could refer to the actual type structure (which would be a change
Nick: related to the WSDL2 support in the current spec), and then the
Nick: 'exchange' is changed so that when it is used to receive a fault (i.e.
Nick: an ExceptionType), the name field is the actual fault name - which could
Nick: map onto WSDL1.1 and WSDL2.
Nick: [is] information type same as fault type in WSDL2 (?)
Charleton: reusability can be achieved w/out eliminating support for both WSDL 1.1 and WSDL2.0 support for WSDL 1.1.
Nick: foultType is an informationType
Nick and Charleton discussed support for faults in WSDL1.1 vs. WSDL2.0
SRT: poc: name of informationType (fault) should be the same as the name of the WSDL2.0 exception type
Nick: When the OPTIONAL attribute exceptionType is set to "true", this Information Type is an Exception Type and MAY map to a WSDL fault type. When the attribute exceptionType is set to "false", this information type MUST NOT map to a WSDL fault type. The default for this attribute is set to "false".
Nick: In case of WSDL 2.0, the attribute element within the informationType refers to a unique WSDL 2.0 faultname when the attribute exceptionType is set to "true".
SRT: Spec is silent on how we deal w/ WSDL1.1 which is a problem for implementors.
Nick: Is this a bug in spec?
SRT: Yes
Nick: Example1 - The informationType "purchaseOrder" refers to the WSDL 1.1 Message type "pns:purchaseOrderMessage"
Nick:
<informationType name="purchaseOrder" type="pns:purchaseOrderMessage"/>
Nick: Look at 5.3 Interface Faults
Nick: The fault element is used to declare faults that may occur during execution of operations of an interface. They are declared directly under interface, and referenced from operations where they apply, in order to permit reuse across multiple operations.
Nick: Faults are very similar to messages and can be viewed as a special kind of message. Both faults and messages may carry a payload that is normally described by an element declaration. However, WSDL treats faults and messages slightly differently. The messages of an operation directly refer to their element declaration, however the faults of an operation indirectly refer to their element declaration via a fault element that is defined on the interface.
Nick: The reason for defining faults at the interface level is to allow their reuse across multiple operations. This design is especially beneficial when bindings are defined, since in binding extensions like SOAP there is additional information that is associated with faults. In the case of SOAP, faults have codes and subcodes in addition to a payload. By defining faults at the interface level, common codes and subcodes can be associated with them, thereby ensuri
Nick: The fault element has a required name attribute that must be unique within the WSDL document's target namespace, and permits it to be referenced from operation declarations. The optional element attribute can be used to indicate a schema for the content or payload of the fault message. Its value should be the QName of a global element defined in the types section. Please note when other type systems are used to define the schema for a fault message, addition
Proposal is at http://lists.w3.org/Archives/Public/public-ws-chor/2005Mar/0021.html
Nick: With this proposal we lose the ability give CDL exception types special status.
Gary: For more complex coors. current CDL requires lots of additional maintenance regarding faults.
Gary: must create an informationType for every fault.
Nick: Would like to know how this impacts the rest of the spec.
Nick: When the OPTIONAL attribute exceptionType is set to "true", this Information Type is an Exception Type and
Nick: Refers to 2.4.1 Information Types
SRT: Question to Nick - If those supporting proposal would show all necessary spec. changes, would the proposal be acceptable?
Nick: If someone does all the work in all areas of the spec. that touch on Exceptions and it makes sense.
ACTION: SRT send email to authors of proposal to provide all necessary editorial changes to the spec to move the proposal forward.
SRT: Changes will still need to be apporoved by the group in order to pass the proposal.
1003 http://www.w3.org/Bugs/Public/show_bug.cgi?id=1003
Summary: RELINGUISHING CONTROL OF PASSED OUTPUT CHANNELS
URL: http://lists.w3.org/Archives/Public/public-ws-chor-comments/2005Jan/0007.html
PROPOSAL: http://lists.w3.org/Archives/Public/public-ws-chor/2005May/0005.html
Latest thread: http://lists.w3.org/Archives/Public/public-ws-chor/2005May/0042.html
REMAIN OPEN
Issue 1003 RELINGUISHING CONTROL OF PASSED OUTPUT CHANNELS
Nick: I am looking for binary answer from Kohei
I have to drop off the call, can someone scribe?
Nick: Channel types are different from pi channels
Nick: either we know what will be there, or we don't and there is no need to add anything now
SRT: You [Nick] said previously that usage was there for people to do model checking
Nick: the model checking is not yet done, and the document will be elsewhere
Nick: the current definition is vague and therefore is difficult to check for validity
Nick: In my CDL code that I sent out to Kohei et. al I want to know a binary "yes", "no": is my program valid or not
Nick: when using the attribute usage="shared"
Nick: this needs to be clear in the spec for all implementers to understand
1001 http://www.w3.org/Bugs/Public/show_bug.cgi?id=1001
Summary: CORRELATION OF CHANNEL INSTANCES
URL: http://lists.w3.org/Archives/Public/public-ws-chor-comments/2005Jan/0006.html
PROPOSAL: http://lists.w3.org/Archives/Public/public-ws-chor/2005May/0016.html
REMAIN OPEN
7. Issues requiring clarification
---------------------------------
9. AOB
-------
MEETING FORMALLY ADJOURNED
SUMMARY OF ACTION ITEMS
-----------------------
1. ACTION: Martin to do UML diagram from scratch for CDL
IN PROGRESS
Status: No change.
2. ACTION: chairs to respond to issue raiser for closed issues
STANDING ITEM
3. ACTION: Yves to define what is meant by correctness
IN PROGRESS - Yves to put text on mailing list this week.
4. ACTION: MC - Close 1110 with the proposed resolution.
IN PROGRESS
Status: No change.
5. ACTION: Martin to record issue 1102 as resolved/later.
IN PROGRESS
Status: No change.
6. ACTION (augments 21 above): Fletcher to complete approved approach for #21.
Status: No change
7. ACTION: Steve and/or Martin to generate a list of the issue numbers that the editing team
should be working on as a spot check.
IN PROGRESS
Status: No change.
8. ACTION: Chairs discuss and provide a recommendation.
Status: No change.
9. ACTION: Kavantzas provide example showing how WS-CDL binds to faults in WSDL1.1 and WSDL1.2 to show the benefit of his approach.
Status: No change.
10. NEW ACTION: SRT send email to authors of proposal to provide all necessary editorial changes to the spec to move the proposal forward.