[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]