Errata
for OASIS Standard WS-Reliability 1.1 (wsrm-ws_reliability-v1.1-spec-os)
Draft 1.0
April 28 , 2005
Document
identifier:
wsrm-ws_reliability-v1.1-errata-cd-1.0
Location:
http://www.oasis-open.org/committees/wsrm/documents/errata/1.1/index.html.
Editor:
Tom Rutt, Fujitsu <trutt@us.fujitsu.com>
In the productions on lines 127 thru 139 of the schema
at:
http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd :
:
“
<xsd:complexType
name="ReplyPatternType">
<xsd:sequence>
<xsd:element name="Value"
type="wsrm:ReplyPatterTypeValues"/>
<xsd:element name="ReplyTo" type="ref:ServiceRefType"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="ReplyPatternTypeValues">
<xsd:restriction base="xsd:string">
<xsd:enumeration
value="Response"/>
<xsd:enumeration
value="Callback"/>
<xsd:enumeration
value="Poll"/>
</xsd:restriction>
</xsd:simpleType>
“
There is an obvious typographical error (No 'n' at the
end of Pattern) on line 129.
“
<xsd:element
name="Value" type="wsrm:ReplyPatterTypeValues"/>
“
should be implemented as if it were the following:
“
<xsd:element
name="Value" type="wsrm:ReplyPatternTypeValues"/>
“
A corrected schema is posted (for information) at:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/11630/ws-reliability-1.1.xsd
The clarifications described in this section relate to group termination tables on page 48
The
entry in Table 27, second row, second column, states the following:
“
(after closing) In case GuaranteedDelivery is not required, remove the group
immediately. Otherwise, remove it if all messages have been either acknowledged
or faulted
“
The
last sentence could be clarified. since it might be
interpreted in either of the two following ways:
(1) All messages are acknowledged, or All
message are faulted.
(2) Zero or more of the messages are acknowledged and all
other messages are faulted.
Common
sense would lead to interpretation 2).
In secton 5.1.3.3, lines
1273 thru 1275 state the following for the sending rmp
termination rules:
“
If GuaranteedDelivery was
required, the RMP MUST remove the group once it has received either
acknowledgment or notification of delivery failure for all sent messages.
“
This confirms that interpretation 2) is the correct
one.
Change
the offending sentence to:
“
In case GuaranteedDelivery
is not required, remove the group immediately. Otherwise, remove it if each message
has either been acknowledged or faulted
“
The
last row of the table 27 could be broken into two separate rows as it contains
many combinations; some of which are not possible.
Given
the condition in the first column:
“
When a group is ordered AND an unacknowledged message
expires or faults.
“
For
this case we cannot have the event “all messages are acknowledged” as a removal
condition.
Change:
change the sentence to:
“ Remove the group after each message has either been acknowledged
or faulted.”
In
the section about group termination, tables 26 and 27 summarize the two events
“group closing” and “group removal” both at the sender RMP and receiver RMP.
These two tables facilitate comprehension of group termination rules for an
implementer. However, they could be enhanced to be clearer.
This
errata item serves to clarify the intent of the tables in the
ws-reliability-1.1 specification
The
tables should be read as if each row was labeled, and the contents of the
second column referred to the label of the row.
Errata
Resolution:
The
tables 26 and 27 should be read with the meaning shown in the following tables
(the changes from 2.1.1 and 2.1.2 have also been applied):
(Section 5.1.3.6)
Conditions for terminating a group in a Receiving RMP
|
Termination case |
Group Closing |
Group Removal |
|
T1 |
When @groupExpiryTime
has passed. |
(after closing) When @groupExpiryTime has passed. |
|
T2 |
When the @groupMaxIdleDuration
time-out has expired. |
(after closing) When Max(ExpiryTime) has passed. |
|
T3, T4 |
When a group is complete. |
(after closing) When Max(ExpiryTime) has passed, (or when @groupExpiryTime
expires, if exists). |
|
T5 |
When a group is ordered AND an undelivered
message expires or faults. |
(after closing) When Max(ExpiryTime) has passed. |
Similarly, Table 27 is extended with a “termination case” column:
Conditions for terminating a group in a
Sending RMP:
|
Termination case |
Group Closing |
Group Removal |
|
T1 |
When @groupExpiryTime
has passed. |
(after closing) When @groupExpiryTime has passed. |
|
T2 |
When the @groupMaxIdleDuration
time-out has expired. |
(after closing) In case GuaranteedDelivery is not required, remove the group
immediately. Otherwise, remove it if each message has either been
acknowledged or faulted. |
|
T3, T4 |
When a group is complete. |
(after closing) In case GuaranteedDelivery is not required, remove the group
immediately. Otherwise, remove it if each message has either been
acknowledged or faulted. |
|
T5 |
When a group is ordered AND an
unacknowledged message expires or faults. |
(after closing) Remove the group after each
message has either been acknowledged or faulted. |
Table 27 Conditions for terminating a group – Sending RMP