- From: Charlton Barreto <charlton_b@mac.com>
- Date: Tue, 7 Dec 2004 14:01:08 -0800
- To: Charlton Barreto <charlton_b@mac.com>
- Cc: public-ws-chor@w3.org
From the Dec 03 draft - includes revisions from today's conf call: 2.5.3 Paragraph 4, lines 32-35: "The perform activity enables a Choreography to specify that another Choreography is performed at this point in its definition, as an enclosed Choreography." Can we change this to, "The perform activity enables a Choreography to specify that another, enclosed Choreography, is performed at this point in its definition." "The performed Choreography even when defined in a different Choreography Package is conceptually treated as an enclosed Choreography." We should change this to: "The performed Choreography, even when defined in a different Choreography package, is conceptually treated as an enclosed Choreography." 2.5.4 Paragraph 1, lines 36-37: "Assign activity is used to create or change and then make available within one Role, the value of one Variable using the value of another Variable or expression". Can we change this to, "The Assign activity is used to create or change the value of one Variable using the variable of another Variable or expression, thereafter making this value available within a single Role." 2.5.4 Paragraph 3, lines 8-9: "When the source defines an expression attribute this MUST contain expressions, as defined in Section 2.4.3." This should be change to, "When the source defines an expression attribute, it MUST contain expressions, as defined in Section 2.4.3." 2.5.5 Paragraph 3, line 31: "The syntax of the silent actionconstruct..." should be changed to, "The syntax of the silent action construct...." 2.5.7 Paragraph 8, lines 3-9: We should change "can have been performed" to "can be performed". "The choreographyInstanceId attribute MAY be omitted if the contract logic of the performing Choreography is such that only one instance of the Choreography identified by the choreographyInstanceId attribute can have been performed when the finalize activity is enabled. If more than one instance of the Choreography identified by the choreographyName attribute can have been performed, the choreographyInstanceId attribute MUST be present." should be changed to: "The choreographyInstanceId attribute MAY be omitted if the contract logic of the performing Choreography is such that only one instance of the Choreography identified by the choreographyInstanceId attribute can be performed when the finalize activity is enabled. If more than one instance of the Choreography identified by the choreographyName attribute can be performed, the choreographyInstanceId attribute MUST be present." 2.5.7 Paragraph 9, lines 12-13: "If the targeted, immediately enclosed, Choreography has only one defined Finalizer Block, then the finalizerName attribute is optional" should be changed to, "If the targeted, immediately enclosed Choreography has only one defined Finalizer Block, then the finalizerName attribute is OPTIONAL." 4 Paragraph 3, lines 31-33: "Because messages can have consequences in the real world, the collaboration parties will impose security requirements on the information exchanges. Many of these requirements can be satisfied by the use of WS-Security [24]." Can we change this to, "The WS-Security specification [24] provides enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication, including a general-purpose mechanism for associating security tokens with messages, and a description of how to encode binary security tokens. As messages can have consequences in the real world, collaboration parties will impose security requirements on their information exchanges. WS-Security can be used satisfy many of these requirements." 6 Paragraph 3, lines 6-7: "Implementing aligned Interactions and coordinated Choreographies requires support from a Coordination protocol, where agreement on the outcome among parties can be reached even in the case of failures and loss of messages." Can we change this to, "Implementing aligned Interactions and coordinated Choreographies requires support from a Coordination protocol, where agreement on the outcome among parties can be reached, even in the case of failure and/or message loss." 7 Paragraph 1, line 1-2: We should move Section 7, "Conformance", to Section 8 (sliding all subsequent sections one section #), and add the following for Section 7: "7 Relationship with Addressing The WS-Addressing specification [28] provides transport-neutral mechanisms to address Web services and messages, specifically, XML [XML 1.0, XML Namespaces] elements to identify Web service endpoints and to secure end-to-end endpoint identification in messages. WS-Addressing enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner. WS-Addressing can be used to convey the reference and correlation information for normalizing expanded channelVariable information into an uniform format that can be processed independently of transport or application. The WS-Addressing specification is in progress and the WS-Choreography Working Group will review and comment on developments in this effort on an ongoing basis." 10 Paragraph 28 (after Paragraph 27; all adjusted for the changes described for Section 7): In the new Section 10, "References" (formerly Section 9), we should add: "[28] Web Services Addressing (WS-Addressing) - W3C Member Submission 10 August 2004"
Received on Tuesday, 7 December 2004 22:01:16 UTC