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: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
