Re: [wsrm] Technical issues as I go through action items...

[Doug Bunting <Doug.Bunting@Sun.COM>]

What restricts the content of a Response message (or element) to 
information about a single group?

On 30-Jul-04 16:55, Tom Rutt wrote:

> I always thought that the reply pattern had to be the same for every 
> message sent in the group.
> 
> If it does not say that, then I agree we have a technical issue to resolve.
> 
> What reason would there be to send a different reply pattern for two 
> messages with the same group ID?
> 
> Tom Rutt
> 
> If we clarified that all messages in a group must have the same reply 
> pattern value, this will simplify each
> return of the response element being from a single reply pattern (i.e., 
> single reply for response reply pattern,
> and batch of callback responses, or a batch of poll responses.
> 
> Doug Bunting wrote:
> 
>> First, my  apologies that the speeded-up  schedule agreed to  on 
>> Tuesday is
>> not coming  true.  While  I strive  to meet your  wishes, I  am 
>> (obviously)
>> falling back to the previous publication schedule.
>>
>> As I finish  up on the action  items, I keep coming back  to section 
>> 4.4.1,
>> "Attribute: Response@replyPattern".  I am unsure  what it is trying to 
>> say.
>> Specific questions for the group:
>>
>> 1. This  attribute  value  is   difficult  to  choose  when  the  
>> published
>>    RM-Replies relate to messages  with varying RM-Reply Patterns.  
>> Only for
>>    an underlying response to a  message with the Response RM-Reply 
>> Pattern,
>>    is  the  choice clear.   For  the  other  RM-Reply Patterns,  
>> which  may
>>    "bundle" information  about multiple Reliable Messages,  how should 
>> this
>>    value be chosen?   As one possibility, must all  described messages 
>> have
>>    arrived using the same RM-Reply Pattern (seems a bit restrictive)?
>>
>>    I note that  the ReplyPattern agreement item has  message scope, 
>> meaning
>>    it may change "randomly" even within a group.
>>
>>    A  potential confusion may  have existed  between the  implied(??) 
>> reply
>>    pattern when responding to a PollRequest versus the reply pattern 
>> of the
>>    queried  Reliable Message(s).  This  case is  already covered  
>> since the
>>    Response@replyPattern value  clearly refers to the reply  pattern 
>> of the
>>    Reliable Message and not the most recent incoming message.
>>
>>    The most  obvious problems  arise when responding  to a  "general 
>> status
>>    query" PollRequest asking about  Reliable Messages with varying 
>> RM-Reply
>>    Patterns but this is not  the only cause for confusion.  More 
>> generally,
>>    the  Receiving RMP  is allowed  to supply  information  about 
>> additional
>>    messages if it  so chooses.  (At least, no  current restrictions 
>> prevent
>>    this.)   For  example,  a  single Callback  publication  may  
>> optionally
>>    include  additional information  about Reliable  Messages  which 
>> arrived
>>    with  other RM-Reply  Patterns (and  which the  Receiving  RMP 
>> "somehow"
>>    knows  were  from  the  same  Sending  RMP).  A  single  response  
>> to  a
>>    PollRequest  may do  the  same,  regardless of  the  number of  
>> RM-Reply
>>    Patterns   relevant  to   the  Reliable   Messages  identified   
>> in  the
>>    PollRequest.   (This is  also  true  for the  underlying  response 
>> to  a
>>    Response RM-Reply Pattern Reliable Message but the "primary" 
>> message and
>>    therefore  @replyPattern value  is  clear  in that  case  and that  
>> case
>>    alone.)
>>
>> 2. The  restrictions identified in  the final  two bullets  prevent 
>> sending
>>    additional information  about other singleton  (no SequenceNum) 
>> messages
>>    when responding to a message received as part of a sequenced 
>> group.  The
>>    SequenceReplies element must  be first in this case  and only 
>> additional
>>    SequenceReplies elements are allowed  according to the 
>> specification and
>>    the schema.   In the opposite  case, a NonSequenceReply element  
>> must be
>>    first  and may  be followed  with additional  NonSequenceReply and  
>> / or
>>    SequenceReplies elements  (though never mixed according  to our 
>> schema).
>>    Was this the intent?  Or, should the schema look more like the 
>> following
>>    DTD?
>>
>>    ( NonSequenceReply | SequenceReplies )+
>>
>>    rather than the current
>>
>>    ( NonSequenceReply*, SequenceReplies* )
>>
>>    Yes, the "1  or more" part is enforced only in  the specification 
>> at the
>>    moment...
>>
>> 3. If this is covered in an action item I missed, please let me know!
>>
>> 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. 
>>
>>
>