Re: [wsrm] Rel YY

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

Sent: Monday, September 29, 2003 11:41 AM

To: Doug Bunting

Cc: ; Jacques Durand; 'Bob Freund';



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