Matt
My firm belief is that the state tables should not "make" any decisions
that are not justified in the text. So I think for every hole or
ambiguity in the tables we need to fix up the text.
I think we should clarify the text to state that the sequence is not
closed or terminated - i.e. it can still accept undelivered messages. Of
course it will not accept new messages.
Paul
Matthew Lovett wrote:
>
> Hi Paul,
>
> That's where these tables get interesting. You could argue that there
> are several implementation choices here (keep using the Sequence,
> close it, terminate it) and they could all have their advocates. The
> tables don't have a notation for "implementation detail". Equally we
> could raise the issue you suggest tighten up in the spec to force a
> choice onto implementers.
>
> I'd be happy with you raising the issue, though I'd need to do some
> more thinking about the implications of picking a single choice. I'd
> also be happy to put a footnote into the table to clarify that cell.
> Any suggestions for text?
>
> Matt
>
>
>
> Paul Fremantle <> wrote on 05/04/2006 16:25:57:
>
> > Matt
> >
> > Am I right in thinking we need a new issue for the decision you made
> > regarding RMD Rollover? I cannot find any words in the spec describing
> > what is acceptable after rollover. (I know its not that likely, but its
> > twice as likely now as it used to be!).
> >
> > Paul
> >
> > Matthew Lovett wrote:
> > >
> > > Hi Paul,
> > >
> > > The columns that were removed were on the RMD side. In the old table
> > > the author had assumed that if a RMD receives a message with a
> message
> > > number greater than the limit, that it entered a new 'rollover'
> state.
> > > I don't believe that state added any value, and don't think that the
> > > main spec mentions, implies or defines it. Having reached that
> > > conclusion I nuked the entire column ;) The state transition that
> now
> > > occurs is that a fault is returned to the sender, but that the RMD is
> > > still in the 'Connected' state, so the RMS may continue to retransmit
> > > earlier messages.
> > >
> > > The majority of the RMS changes are to ensure that each cell contains
> > > both an action and a next state, as the gaps were potentially
> misleading.
> > >
> > > The RMD table changes as mentioned above, and I also clarified the
> > > rows corresponding to message arrival (with message number in
> range vs
> > > message number out of range).
> > > I removed the RMD row corresponding to "Unrecoverable error on
> > > creation" as I don't think a sequence would be created at all in that
> > > case.
> > >
> > > I removed the RMD retransmitted message row as the RMD won't always
> > > know if a message is retransmitted (the first transmission might have
> > > been completely lost). The main message received row should be robust
> > > enough to deal with this, and further detail sails close to RMD/AD
> > > communication issues that are out of scope.
> > >
> > > I removed the RMD "message rollover fault" row, as an RMS is never
> > > going to send that fault to an RMD.
> > >
> > > I removed the RMD "terminate sequence" row as it was a duplicate (see
> > > 3 rows above).
> > >
> > >
> > > I hope that helps! Thanks for asking - I'm sure that you were not the
> > > only person who wanted a guide to the changes.
> > >
> > > Cheers,
> > >
> > > Matt
> > >
> > >
> > >
> > >
> > >
> > > *"Paul Cotton" <>*
> > >
> > > 05/04/2006 14:55
> > >
> > >
> > > To
> > > Matthew Lovett/UK/IBM@IBMGB, <>
> > > cc
> > >
> > > Subject
> > > RE: [ws-rx] Issue i096
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Could you give us some explanation of the changes? In particular why
> > > are you proposing to remove two complete columns?
> > >
> > >
> > > Paul Cotton, Microsoft Canada
> > > 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
> > > Tel: (613) 225-5445 Fax: (425) 936-7329_
> > > __mailto:[email protected]_
> > >
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > > *From:* Matthew Lovett [mailto:] *
> > > Sent:* April 5, 2006 9:32 AM*
> > > To:* *
> > > Subject:* [ws-rx] Issue i096
> > >
> > >
> > > Hi all,
> > >
> > > Here's an updated PDF for the state tables. There are quite a few
> > > updates, all highlited in blue. If this proposal is accepted by the
> > > TC, I think this leaves the tables in a reasonable state (no pun
> > > intended), so if anyone has any further ideas for changes they are
> > > probably best handled under new, specific issues.
> > >
> > >
> > >
> > > I also have the openoffice doc that produced the PDF - it may be
> > > useful for the editors if the TC accepts the proposal.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Matt
> > >
> >
> > --
> >
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://feeds.feedburner.com/bloglines/pzf
> >
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://feeds.feedburner.com/bloglines/pzf
"Oxygenating the Web Service Platform", www.wso2.com
