RE: [wsrm] SequenceNumber element

[Scott Werden <scottw@wrq.com>]

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