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>

 

1           Typographic Error

1.1         ReplyPatterType -> ReplyPatternType in ws-reliability-1.1.xsd

 

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

 

 

2         Clarification of Potential Ambiguities

2.1      Group Termination Summary Table Clarifications

The clarifications described in this section relate to group termination tables on page 48

2.1.1      Table 27 Second Row Clarification

 

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

 

2.1.2      Table 27 Final Row Clarification

 

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.”

 

 

 

2.1.3      Clarification on How to read Tables 26 and 27

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