[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Rel YY
Sunil Kunisetty wrote: >Tom Rutt wrote: > > > >>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. >> >> > > You mean instead of the proposed MessageOrder element in Request ( I guess > that's what you meant below by saying rm-orderRequested). > > 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. > > Infact, that's the reason I preferred SequenceNumber as optional and non > existence of SequenceNumber to distinguish as an independent message > rather than having it and value be 0. > > > It simplifies processing if all things having to do with the use of sequence number occur together in the message. That way you do not have to look at another header to determine if the ordered delivery is requred. The point is our existing syntax covers the semantics well. Why add another element to another header (messageOrder element). We already moved the status attrbute to sequenceNumber, why move it back? Tom Rutt > > >>Thus the sequence Number would be optional with an optional status >>attribute. >> >>This does not change our existing syntax, only the semantics. >> >> > > Yes, it will change the syntax, but it won't be that complex. Infact, we used > to have it (MessageOrder) before. > > > >>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/leave_workgroup.php. >> >> > > > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]