[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 102 - WS-AT: Editorial comments
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."
==> 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”.
==>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.
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.
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]