Re: Fw: [ws-tx] Issue 030 - consolidated refinement of Proposal 2

[Mark Little <mark.little@jboss.com>]

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