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] Technical issues as I go through action items...


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

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





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