[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Fw: [ws-tx] Issue 030 - consolidated refinement of Proposal 2
Some proposed amendments: WS-C, currently: "The protocol faults defined in this section are generated if the condition stated in the preamble is met. When used in a transaction protocol, these faults are targeted at a destination endpoint according to the protocol fault handling rules defined for that protocol." change to "The protocol faults defined in this section are generated if the condition stated in the preamble is met. When used in by a Referencing Specification, these faults MAY be targeted at a destination endpoint according to the protocol fault handling rules defined for that specification." I'd also recommend we define Referencing Specification at the start of WS-C. The reason for the change is that a) in the second paragraph on the first page we (correctly) don't limit the applicability of WS-C to just transaction protocols, and b) we cannot know all possible uses of WS-C even in transaction protocols, so therefore we should not enforce one mechanism over another. I think MAY is strong enough for WS-C, and then WS-AT/WS-BA can use SHOULD/MUST where necessary. WS-AT, currently: "The protocol faults defined in this section are generated if the condition stated in the preamble is met. When used in a transaction protocol, these faults are targeted at a destination endpoint according to the protocol fault handling rules defined for that protocol. " Since we know that WS-AT is a transaction protocol, this text looks odd. I'd suggest: "The protocol faults defined in this section are generated if the condition stated in the preamble is met. These faults SHOULD be targeted at a destination endpoint according to the fault handling rules defined for that protocol. " And a slight rewording of: "Protocol faults raised by a Coordinator or Participant during the processing of a notification message defined in this specification are composed using the same mechanisms, described in this section, as other terminal notification messages. " to "Protocol faults raised by a Coordinator or Participant during the processing of a notification message are terminal notifications and MUST be composed using the same mechanisms as other terminal notification messages. " Mark. Ian Robinson wrote: > > > There has been a lot of discussion and some good comments suggesting > refinement of "Proposal 2" for issue 30. Specifically: > Alastair's point that the WS-C spec defines the Coodination faults as > "reply messages" but the WS-AT spec defines AT faults as "notification > messages". The refined proposal clarifies that the specific messages > exchange patterns apply to the protocol rather than to individual > messages and that protocol fault messages are constructed according to > the rules of the protocol in which they are used. > Bob's objection to the use of phrases like ' "one way" pattern as > defined in WS-Addressing '. The proposal replaces this with ' The > protocols defined in WS-AtomicTransaction use a "one way" message > exchange pattern consisting of a sequence of notification messages > between a Coordinator and a Participant. ' > Joe's observation of the inconsistency in specificity between references > to WS-A from Coordination on the one hand and AT on the other. These are > now uniformly precise. Also the proposed text now refer to the abstract > message addressing properties rather than to soap header elements. > > Max and I have updated our proposal to address these concerns. > > (See attached file: Issue30_Proposal_2_WSBA.doc)(See attached file: > Issue30_Proposal_2_WSAT_updated.doc)(See attached file: > Issue30_Proposal_WSCOOR_updated.doc) > > In accrodance with the decision of the TC on the last telecon, the text > remains silent on the handling of non-TX fault messages. > > We have been discussing this issue for a month now, and we have other work > queued up. Could I suggest that any further refinements or > counter-proposals be written in terms of concrete spec language that the TC > would be able to vote upon on the next telecon. > > > Regards, > Ian
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]