RE: [wsrm] Rel YY

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: RE: [wsrm] Rel YY

Sunil, Bob,

I think your revised proposal is compatible with the concerns that
motivated mine.

I guess your reason for adding category 3, is that from an implementation
point of view, you do not want to have the overhead of group creation
for each message, since there is no way to know its a singleton ??

Still trying to stick with 2 categories, for the sake of schema simplicity and consistency, wouldn't a new value of "unique" for @status of sequence number,

do the job of identifying group singletons (category 3)?
("unique" meaning at the same time "start" and "end")
(note that, regardless of our problem at hand, we should technically allow for this !)
Of course, it is a bit more verbose protocol-wise than just GroupID.

> I prefer MessageOrder (or what ever is the name) sub-element as the
> triggering mechanism rather than the value of some attribute or sub-element
> to distinguish the category.

I favor this too: more consistent with what we do for ack requested, dup elimination.

Jacques

-----Original Message-----
From: Bob Freund [mailto:Bob.Freund@hitachisoftware.com]
Sent: Friday, September 26, 2003 1:59 PM
To: tom@coastin.com; Sunil Kunisetty
Cc: Jacques Durand; wsrm@lists.oasis-open.org
Subject: RE: [wsrm] Rel YY

That is something I could support.

> -----Original Message-----
> From: Tom Rutt [mailto:tom@coastin.com]
> Sent: Friday, September 26, 2003 4:52 PM
> To: Sunil Kunisetty
> Cc: Jacques Durand; 'wsrm@lists.oasis-open.org'
> Subject: Re: [wsrm] Rel YY
>
>
> Sunil Kunisetty wrote:
>
> > 
> >  Jacques,
> >
> >  Oracle will be supporting this proposal. However, I prefer that
> > SequenceNumber
> >  be Optional rather than mandatory as you indicated in (P2). I
> > understand that it will
> >  be difficult for schema validation, but I believe it will be much
> > simpler and efficient
> >  for implementations.
> >
> >  So essentially we should categorize all RM  into 3 different
> > categories based on
> >  the elements used in RM Headers:
> >
> >  1) Grouped and Ordered Messages:          Group Id + Seq No.  +
> > Message Order
> >                                                            
>          
> > Same Group Id, Different Seq No.
> >
> >  2) Grouped and Un-Ordered Messages:    Group Id + Seq No.
> >                                                            
>          
> > Same Group Id, Different Seq No.
> >
> >  3) Discrete & Independent RM Messages: Group Id
> >
> >  We could then use the SequenceNumber sub-element has the toggle
> > switch to
> >  distinguish Grouped Un-ordered with Discrete & Independent
> messages.
> >
> We could then use the presence of the SequenceNumber's status
> attribute
> (an enum with first, more, and last) as the trigger for
> ordered delivery
> of the sequenced group.
>
> Thus the sequence Number would be optional with an optional status
> attribute.
>
> This does not change our existing syntax, only the semantics.
>
>
> This way we would not need a separate rm-orderRequested
> header subelement.
>
> Tom Rutt
>
> > An
> >  implementation could then use 3 different Hash Tables to store the
> > IDs, thus
> >  making DE much more efficient.
> >
> ----------------------------------------------------
> Tom Rutt              email: tom@coastin.com; trutt@fsw.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>
>
>
>
>
> 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/leav
> e_workgroup.php.
>
>

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.