[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 102 - WS-AT: Editorial comments
On 20 Oct 2006, at 15:24, Ian Robinson wrote: > We never finished discussing this issue on the telecon so here are > some > email comments: > > First of all, we *did* start but not conclude the discussion on: > ==> Line 24: Change “Tentative actions visible to” to “tentative > actions persistent and visible to”. > > > > > I agree that this simply observes an inconsistency in the text but, if > we're going to change it, I wonder if we should be generally more > precise > in this section. The AT Coordinator has no control over the > persistence or > the visibility of the Actions it coordinates through the registered > Participants - the AT Coordinator *only* provides the application with > atomicity. Making coordinated actions persistent and visible is the > job of > the Participants or the resource managers they delegate to. So I > would like > to suggest that we change the text at lines 19-26 from: > > > "The actions taken prior to commit are only tentative (i.e., not > persistent > and not visible to other activities).... Commit makes the tentative > actions > visible to other transactions. Abort makes the tentative actions > appear as > if the actions never happened." > > > to: > > > "The actions taken by a transaction participant prior to commit are > only > tentative (and so typically are neither made persistent nor made > visible to > other activities)...Commit directs the participants to make the > tentative > actions final so they may, for example, be persisted and made > visible to > other transactions. Abort directs the participants to make the > tentative > actions appear as if the actions never happened." Slight mod to last sentence "Abort directs the participants to make it appear as though the tentative actions never happened." > > > > > ==> Line 216: Change “Once this has happened” to “Once the > coordinator > issues a Prepare”. > > I think this loses something. Perhaps: > > “Once the coordinator has issued a Prepare to a Durable2PC > participant”. +1 > > ==>6. Section 3.3.2 > d. Line 235: should -> SHOULD > I think this has to be MUST to be consistent with the the state > table (and > 2PC in general). > i.e If the participant has already voted, it MUST resend the same > vote. +1 > > i. Line 258 – Which 2PC protocol? Both? > > Since Section 3.3 defines "The 2PC protocol has two variants: > Durable 2PC > and Volatile 2PC. " then I believe "both" can be implied without > needing > further clarification. +1 Mark. > > > Regards, > Ian > > > > > Ram Jeyaraman > <Ram.Jeyaraman@mi > > crosoft.com> To > "ws-tx@lists.oasis-open.org" > 16/10/2006 23:02 <ws-tx@lists.oasis-open.org> > > cc > > > Subject > [ws-tx] Issue 102 - WS-AT: > Editorial comments > > > > > > > > > > > This issue is identified as 102. > > Please use the subject line for future correspondence on this > issue: "Issue > 102 - WS-AT: Editorial comments". > > From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com] > Sent: Sunday, October 15, 2006 7:25 PM > To: ws-tx@lists.oasis-open.org > Subject: [ws-tx] NEW Issue - WS-AT: Editorial comments > > Protocol: WS-AT > > Artifact: spec > > Draft: WS-AT specification PR 01 > > Link to the document referenced: > http://www.oasis-open.org/committees/download.php/20224/wstx- > wsat-1.1-spec-pr-01.doc > > > > Section and PDF line number: See description below. > > > Issue type: Editorial > > > Related issues: None > > Issue Description: > 1. Line 2: “The current set of Web service > specifications [WSDL > ][SOAP11][SOAP12] defines protocols for”; Change “defines > protocols” > to “define protocols”. > 2. Line 19: Change “When an application finishes,” to > “When an > application finishes working on a transaction,”. > 3. Line 24: Change “Tentative actions visible to” to > “tentative > actions persistent and visible to”. > 4. Line 30: Change “existing transaction processing > systems to > wrap their” to “existing transaction processing systems will use > WS-AtomicTransaction to wrap their”. > 5. Section 1.2 Terminology >> Namespace URIs of the general form "some-URI" represents some > application-dependent or context dependent URI as defined in > RFC3986 > [URI]. > This feature is never used in this specification. Remove > text from > the specification. > 6. Section 1.4, replace line 72 with “The XML schema > and the > WSDL declarations defined in this document can be found at the > following locations:” > 7. Section 1.6 Normative References. Use correct SOAP > version > 1.2 link is http://www.w3.org/TR/soap12-part1/. > 8. Section 2 > a. Fix grammar: > i. Before: “which defines an activation and a > registration service. “ > ii. After: “which defines an activation > service and > a registration service. “ > b. Line 148 – add a colon (:) at the end of the > sentence. > 9. Section 3 > a. Line 161 - add a colon (:) at the end of the > sentence. > b. Editorial: > i. Before: “the coordinator begins with > Volatile 2PC > then proceeds through Durable 2PC” > ii. After: “the coordinator begins with > Volatile 2PC > and then proceeds through Durable 2PC” > c. Line 178 – I’m not sure what precisely it > means to > have a security context, and yet we MUST have one. > CKaler may > want to review this. > 10. Section 3.1 > Lines 176-177 - Replace the two occurrences of MUST with SHOULD, > since it is not always possible to expect the client to know > all the > server-side policies). > Lines 178-179 – Replace the sentence with the following: “If > a secure > exchange of messages is required, then the source and > destination > MUST have appropriate security credentials in order to > protect the > messages”. > 11. Lines 209-210: Change “The 2PC protocol has two variants: > Durable 2PC and volatile 2PC.” to “The 2PC protocol has two > variants: > Volatile 2PC and Durable 2PC.” > 12. Line 216: Change “Once this has happened” to “Once the > coordinator issues a Prepare”. > 13. Line 224: Change “After receiving a” to “Upon receiving > a”. > 14. Line 226: “All participants registered for this > protocol must > respond”; change ‘must’ to “MUST” > 15. Section 3.3.1 > a. Line 213: must -> MUST > b. Line 214: may -> MAY > c. Line 219 nit – protocol is different color > than other > protocol. > 16. Section 3.3.2 > a. Line 223: must -> MUST? (Not sure about this > one.) > b. Line 226 nit – again, the color. > c. Line 234: must -> MUST > d. Line 235: should -> SHOULD > e. Line 238: can -> MAY > f. Line 238: may -> MAY > g. Line 242: can -> MAY > h. Line 243: must -> MUST > i. Line 258 – Which 2PC protocol? Both? > 17. Section 4 states: ““this specification defines a pair > of Atomic > Transaction policy assertions that leverage the WS-Policy > framework”. > But the specification defines only assertion. This quoted > text should > be modified as: “this specification defines an Atomic > Transaction > policy assertion that leverage the WS-Policy framework”. > 18. Section 4.4 > Line 318 should be “Lines (8-11) are a policy expression that > includes an AT policy assertion (Line 9) to indicate” > Line 320 should be “Lines (13-19) are a WSDL [WSDL] binding. > Line > (16) indicates that the policy in Lines (8-11) applies” > 19. Section 5 > a. Line 331: Is it really correct to refer to > [Reason] as > “the English language reason element”? Suggestion: > Change to > “[Reason] a human readable explanation of the fault”. > 20. Section 8. WS-AT section 8 refers to Section 3.3 of WS- > A to > construct a message to the [source] EPR, when appropriate, > but there > should be a similar statement when it’s using the EPR it had > already > obtained. Add “Notification messages are normally addressed > according to Section 3.3 of WS-Addressing by both > coordinators and > participants using the Endpoint References initially obtained > during > the Register-RegisterResponse exchange.” > 21. Line 513: Change “and probably fatal” to “and probably > a fatal > condition”. > 22. Section 9 State tables. Change ‘ReadOnlyDecision’ to > ‘Read Only > Decision’. > 23. Section A > Line 525: Jim Johnson (Microsoft) is missing in the > acknowledgement > section. Jim is one of the authors of the contributed AT > specification. Add “Jim Johnson (Microsoft)”. > Line 525: Chris Kaler (Microsoft) is missing in the > acknowledgement > section. Chris is one of the authors of the contributed AT > specification. Add “Chris Kaler (Microsoft)”. > Line 525: Replace “Max Feingold (Microsoft)” with “Max Feingold > (Microsoft) (Editor)”. > Check with Peter Furniss to use the right affiliation > description. > 24. All bulleted items in the specification: Indent one > level deep. > > Proposed resolution: See issue description.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]