Re: [wsrm] Rel YY

[Sunil Kunisetty <sunil.kunisetty@oracle.com>]

 Jacques,

 Few minor comments inlined:

Jacques Durand wrote:

 

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)

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

 The schema has changes from approved resolutions only.
Since
 we haven't decided on this, we didn't include this.
>  
> 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.
  I thought of another reason why we should use presence
of MessageOrder
  element had the trigger for Ordering instead of
Seq No. as 0 . Since Ack
  Requested & Duplicate Elimination are implicit
in the Ordering case, if
  we don't have the MessageOrder element, then Seq
No > 1 will indicate
  implicit DE & Ack Requested. That leads to
a convoluted relationship
  between the 2 Header elements (MessageHeader &
Request). Where as
  if we use MessageOrder element, it will have an
implicit dependency
  on sub-elements within the same Header.
 
 
>  
> 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?
  For consistency sake, we need to mandate this sub-element
in all the Grouped-Ordered
  cases especially when the trigger for Ordering
is based on the existence of this
  element.
>  
> (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
 Yes we shouldn't allows the mixed mode. A group is
completely ordered or un-ordered.
  A mixed mode will be very complicated and un-warranted.

DuplicateElimination,
since these two features are required with Ordering.

 Jacques
 

-----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';
wsrm@lists.oasis-open.org
Subject: Re: [wsrm] Rel YY
 

 Doug,

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

 Agree.

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

 -Sunil