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