OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsrm] proposed wording for bullet in 4.5


Title: RE: [wsrm] proposed wording for bullet in 4.5

Rewording for 1.01:
- either solution is fine with me.

Rewording lines 949-951 :
- while I understand the concern, "do not rely exclusively on SOAP Faults" would suggest we
still rely a good deal on it even if not completely,
when in fact we do not rely at all in 99% of cases.
How about "only rely marginally on the SOAP Fault model..." instead?

Jacques


R-----Original Message-----
From: Doug Bunting [mailto:Doug.Bunting@sun.com]
Sent: Tuesday, June 08, 2004 5:26 PM
To: wsrm@lists.oasis-open.org
Subject: [wsrm] proposed wording for bullet in 4.5


During the call, our primary discussion began with the second to last
bullet in section 4.5.  In the 1.1-1.02 draft (as shown in the footer),
sometimes called "1.01" and published 4 June 2004, this bullet appears at
lines 958 though 964.  I believe these comments overlap Tom's suggestions
in his "Detailed Editorial Fixes for Sections 1 - 4 of ED 1.01" email
identified as for "Line 961 through 965".

Please note that this section is entitled "Fault Codes for Reliable Message
Failures".  As such, it is specific to faulting.

The text reads in 1.01:

"
In case of a Response RM-Reply Pattern was required, and when the message
cannot
be delivered to the Consumer due to a failure in processing the RM headers,
then a
SOAP Fault MUST be generated in addition to the RM-Reply that contains the
RM Fault.
Because either a well-formed response or a SOAP Fault is expected on the
sending
side, then the response leg of the transaction MUST contain a SOAP Fault in
the SOAP
Body when no business response is available. More details are given in the HTTP
Binding section.
"

Taking two of Mark Peel's suggestions (for line 958), one of Tom's
(removing "that contains the RM fault") and the clarity we found during the
teleconference, the new bullet would read:

"
When the Response RM-Reply Pattern is in use and the message cannot be
delivered to the Consumer, the underlying protocol response MUST contain a
SOAP Fault (in the SOAP Body) in addition to the appropriate RM Fault (in
the SOAP Header).
The sending RMP and producer expect either a complete response or a SOAP
Fault when using the Response RM-Reply Pattern and this requirement
satisfies those expectations.
More details are given in the HTTP Binding section.
"

We have not previously discussed the second or third sentences of this
draft.  The above changes remove some duplicate text from the second
sentence, moves some into the first sentence and rewords the remainder.  If
the group prefers less editorial changes and limiting the updates to the
first sentence, I would suggest at least removing an extraneous "then" from
the second.  The new first sentence for this alternative would be:

"
When the Response RM-Reply Pattern is in use and the message cannot
be delivered to the Consumer, a
SOAP Fault MUST be generated in addition to the RM Fault.
"


Separately, lines 949-951 include the following sentence:

"
These protocol specific fault codes are
returned by the Receiving RMP within the response header element. Reliable
Message Faults are
carried in the SOAP Header, and do not rely on the SOAP Fault model for the
following reasons:
"

I believe the "do not reply" phrase is somewhat historical since SOAP
Faults have been added and removed at various times.  I suggest saying "do
not reply exclusively" instead.  The full sentence would then be:

"
These protocol specific fault codes are
returned by the Receiving RMP within the response header element. Reliable
Message Faults are
carried in the SOAP Header, and do not rely exclusively on the SOAP Fault
model for the following reasons:
"

thanx,
        doug


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]