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] Rel YY

Title: RE: [wsrm] Rel YY

I would like to summarize what I believe the "amended RelYY" proposal is currently,
so as to make progress on submitting it, as it is one of these features
that is on the critical path of implementors...

- There will be three ways to "sequence" (or not) messages within a group:

(1) when ordering is required:
        GroupId + SequenceNumber + MessageOrder 

(2) when ordering is not required, but for other benefits
(here the possibility of fast/space efficient duplicate check)
        GroupId + SequenceNumber

(3) when ordering is not required, but no other use of sequences is desired,
there will be only one message per group, identified by group Id:
        GroupId (and no SequenceNumber element)

- each GroupId is globally unique.
- in both cases (1) and (2) SequenceNumber values must be unique within a group,
and generated as a contiguous sequence (modulo...)
- in both cases (1) and (2), the status attribute on SequenceNumber is allowed values
"Start" "Continue" "End" according to similar rules. (does Doug agree here?)

NOTE1: Sunil did not reintroduce MessageOrder  in his latest schema yet.
I personally favor this over a lower level way to signal the Ordering feature:
it is more consistent with what we do with AckRequested and DuplicateElimination.

NOTE2: Along the line of what are the rules in using combinations of header elements:
Since the Ordering feature applies to an entire group, and that it is no longer
signaled by the presence of SequenceNumber under this proposal,
should we  consider significant the "MessageOrder" (or whatever signal)
in the first message only of the group?
(or few first ones in case we need to handle the special case of the first one missing / delayed)
otherwise, if we keep a per-message semantics, having a mix of messages with/without such signal
should NOT be allowed in a group. And the question extends to AckRequested and DuplicateElimination,
since these two features are required with Ordering.


-----Original Message-----
From: Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com]
Sent: Monday, September 29, 2003 11:41 AM
To: Doug Bunting
Cc: tom@coastin.com; Jacques Durand; 'Bob Freund';
Subject: Re: [wsrm] Rel YY


Doug Bunting wrote:

> Tom and Sunil,
> Is this issue about preferences against attributes or against using
> attributes to drive somewhat larger decisions?  I am primarily curious

It's the latter.

> though it might make me lean one way or the other.
> At the moment, one thing seems necessary to me is preventing a sender
> including a request for ordering but no sequence number or ending a

 If the decision making is based on the values of the attributes or elements,
 we cannot enforce it by schema.

> group that is not ordered.  How exactly those things are tied together
> and how the schema prevents four or six categories where only three have
> "meaning" seems much less important.  But, I would certainly prefer the
> proposed MessageOrder element or similar attributes *not* be allowed (in
> the schema, not just the text) without the existing SequenceNumber element.

 Both the proposals (Jacques's  initial proposal and my amended one) do require
 SequenceNumber. The only difference is I wanted it to be Optional, where as
 Jacques wanted it to be mandatory.

> I also believe (going the other way) that it is better to restrict a
> messaging schema so that each thing you want to "say" can be said in


> only one way.  If we re-introduce the MessageOrder element or add more
> to the SequenceNumber attributes to introduce the same categorization,
> we should remove any (overlapping) special semantics for a
> SequenceNumber of 0.

 At this time we are only listing alternate choices. We eventually have to pick one,
 not both.


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