Re: [wsrm] Proposal to resolve rel 108/115

[Tom Rutt <tom@coastin.com>]

Sunil Kunisetty wrote:

>Tom Rutt wrote:
>
>  
>
>>Sunil Kunisetty wrote:
>>
>>    
>>
>>>Tom Rutt wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>Sunil Kunisetty wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Tom,
>>>>>
>>>>>Why not simply add a sub-element by name FaultCode to
>>>>>SequenceNumberRange.
>>>>>It will be of cardinality of minOccurs=0. If present, then that range
>>>>>messages have
>>>>>fault. If not, they are non-fault messages.
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>because there are singlton groups which do not have the sequence number .
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>Duh! forgot about that. In that case, we could have this element/attribute of the
>>>RefToMessageId itself and define the scoping rules clearly.
>>>
>>>I prefer not to have different sections for fault and normal messages in the
>>>Response.
>>>
>>>
>>>      
>>>
>>But won't this cause the group ID to be repeated if you are reporting
>>both delivered and faulted message IDs for the same group.?
>>    
>>
>
> No. here are some  examples.
>
> For a fault with singleton  case:
>
> <Response>
>     <RefToMessageId groupId="http://www.oracle.com";  faultCode="....">
>  </Response>
>
The schema I proposed would look like the following for this case:

<Response 
xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1"; 
soap:mustUnderstand="1">
      <RefToMessageReplies groupId="http://www.altova.com/1";>
            <RefToFaults>
                  <FaultCode>wsrm:InvalidMessageHeader</FaultCode>
            </RefToFaults>
      </RefToMessageReplies>
</Response>

A little more verbose, but still readable.

>
> For a grouped case:
>
>  <Response>
>    <RefToMessageIds groupId="http://www.altova.com";>
>          <SequenceNumberRange from="4294967291" to="4294967295">
>                 <FaultCode>wsrm:InvalidMessageHeader</FaultCode>/
>           </SequenceNumberRange
>           <SequenceNumberRange from="4294967296" to="4294967298"/>
>    </RefToMessageId>
>   </Response>
>
In this case my proposed schema would make the response look like the 
following:

<Response 
xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1"; 
soap:mustUnderstand="1">
      <RefToMessageReplies groupId="http://www.altova.com/1";>
            <RefToFaults>
                  <FaultCode>wsrm:InvalidMessageHeader</FaultCode>
                  <SequenceNumberRange from="4294967295" to="4294967295"/>
            <RefToFaults>
            <SequenceNumberRange from="4294967295" to="4294967295"/>
      </RefToMessageReplies>
</Response>

This is just as readable as your example, and uses a consistent schema 
construct for reporting singleton and non singleton groups.

It also uses sequenceNumberRange consistently with the way it is used in 
poll request.

My biggest concern is your proposal has two different ways to send the 
fault code, as an attribute for singleton groups, and as
a subelement of sequence number range for non singleton groups.

The syntax i proposed also allows sequential processing of the sequence 
number ranges.



>
>  Note that group id is  mentioned only  once per group.
>
>  While there are advantages with this approach, such as:
>         - No new elements
>
however your proposal requires two types of sequence number rangee.

>         - Potential sequential processing of acks and faults, i.e.,
>           response will 1-4 are acks, 5-6 are faults, 7 is an Ack,
>           8,9 are faults etc...
>
>  There are also some dis-advantages:
>      - Schema validation will be difficult
>
Because there are two ways to send fault code, depending of singleton vs 
non singleton group.

>      - Need to explain scoping rules more clearly.
>
> As I also mentioned earlier, PollRequest also refers to the same
> SequenceNumberRange. To solve this,
>   i) we can maintain both sets of SequenceNumberRange, with different names,
>      and refer one with faults to response and one without faults to poll-request.
>    ii) or use the same element and mention in the spec. that
>        poll-request should not  have the FaultCode sub-element.
>
>  
>
>>    
>>
>>>      
>>>


-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133