Re: [wsrm] SequenceNumber element

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

Scott Werden wrote:

> See below....
> Scott
>
> > -----Original Message-----
> > From: Tom Rutt [mailto:tom@coastin.com]
> > Sent: Tuesday, September 16, 2003 5:27 PM
> > To: Scott Werden
> > Cc: wsrm@lists.oasis-open.org
> > Subject: Re: [wsrm] SequenceNumber element
> >
> >
> > Scott Werden wrote:
> >
> > >I propose that SequenceNumber element be required, but the
> > text say that it
> > >will be ignored (or perhaps we can say it must be empty)

 It will be user un-friendly to ask or send something that will be
 eventually ignored. I'm strong believer of "ask the user only
 when required" kind of philosophy.

 Since we are anyway having this discussion, I still prefer my initial
 proposal to move SeqNo as an sub-element of MessageOrder
 element under 'Request'.

 The only (minor) problem in this case is that the Header is split
 between 2 different Headers which I believe is okay as it is just
 an implementation issue which is  (Header structure) anyway
 opaque to the user. And as such SeqNo. is only used for
 Message Order case, so they (RMPs) need to anyway look
 into the Request Header.


>
> > except for when

>
> > >message ordering is being used. It makes header processing a
> > little cleaner
> > >and certainly makes the schema more precise. Having a header element
> > >required or disallowed depending on the presence of an element (the
> > >DuplicateElimination element) in a different header block
> > seems a little
> > >strange to me.
> > >
> > It seems that Scott and Jacques were not present when we voted to
> > simpify the semantics by
> > making SequenceNumber conditional (and actually signalling)
> > on the use
> > of ordered delivery.
>
> >
> > The sequence Number is now the signal that ordered delivery is
> > required.  The sequence status is now an attribute of the sequence
> > number.  We took away the orderedDelivery element when we
> > made Sequence
> > number optional.
> >
> > If we were to entertain a new issue, the proposers would have
> > to explain
> > the semantics of using sequence numbers other than 0 when ordered
> > delivery is not required.
> >
>
> I am not proposing new semantics at all. SequenceNumber is not used by any
> feature other than Ordering, and this will stay the same. My proposal has
> two benefits:
> (1) SequenceNumber element will always be present, so the semantics of the
> protocol will match the schema. Right now, the SequenceNumber is optional
> from the perspective of the schema, but it really isn't optional - sometimes
> it is REQUIRED. That sort of mismatch with the schema defeats the purpose of
> schema.
> (2) The elements which enable features (guaranteed delivery, ordering,
> duplicate elimination) will all be located under the same header (the
> Request header) rather than split.
>
> > In my opinion, as chair, we should have another proposal basically
> > agreeed on email discussions for replacement text before actually
> > opening a new issue which overturns the resolution of a
> > previous issue.
> >
> > What do you think scott and Jacques?
> >
> > Tom Rutt
> >
> > >
> > >Scott
> > >
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com]
> > >>Sent: Tuesday, September 16, 2003 12:00 PM
> > >>To: wsrm@lists.oasis-open.org
> > >>Subject: [wsrm] [Rel-87]schema for Headers
> > >>
> > >>
> > >>
> > >> All -
> > >>
> > >> Before Scott & I work on the Schema for the RM Headers, we
> > >>would like to
> > >> know that this is what we have decided so far. Please
> > >>correct us if we missed
> > >> something or didn't capture any resolution properly.
> > >>
> > >> -Sunil
> > >>
> > >>--------------------------------------------------------------
> > >>-------------------------------
> > >>MessageHeader
> > >>     - GroupId - "mid URI" scheme from RFC2392 - Mandatory
> > >>     - SequenceNo - unsignedLong - Long
> > >>       --   status attribute - xsd:string -  Begin, Continue, End
> > >>     - TimeStamp  - UTC  - Mandtory
> > >>     - ExpiryTime  - UTC - Mandatory
> > >>     - ReplyPattern -  xsd:string  - Optional
> > >>       - replyTo attribute - uri  - Optional
> > >>
> > >>Request
> > >>     - AckRequested  - Optional
> > >>     - DuplicateElimination  - Optional
> > >>
> > >>Response
> > >>   RefToGroupId - "mid URI" scheme  from RFC2392 - Mandatory
> > >>   RefToSequenceNo - unsignedLong - Optional
> > >>
> > >>Fault - QName - Mandatory
> > >>
> > >>Namespace:
> > >>
> > >>  urn:oasis:names:tc:wsrm:schema:1.1:SOAP1.1
> > >>   urn:oasis:names:tc:wsrm:schema:1.1:SOAP1.2
> > >>
> > >>URL Location:
> > >>
> > >>
> > >>
> > >  http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1
> > >  http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.2
> > >
> > >
> > >-------------------------------------------------------------
> > ---------------
> > >---------------------
> > >
> > >
> > >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/lea
> > ve_workgroup.ph
> > >p.
> > >
> > >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.
> >
> >
> >
>
> --
> ----------------------------------------------------
> 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.