I agree there are
more ? than in your post. There are a number of differences that make your
proposal difficult to evaluate though. Specifically there is a break in your
tables that does not occur in WD12 that separates events that cause state
transitions and those that don’t. There are also some events that are in
both the RMS and RMD tables that are only in one or the other in your proposal,
one example is “elapse expires duration”.
What motivated the
change of connecting/connected to activating/activated?
The division of the
events into generate/receive greatly complicates these tables, are you
convinced it really provides additional clarity?
From: Durand, Jacques
R. [mailto:JDurand@us.fujitsu.com]
Sent: Tuesday, May 02, 2006 7:47
PM
To: Marc Goodner; Matthew Lovett
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] More on i113
Mmmh… I have been using the latest
source provided to me by Matt Lovett I believe.
Looking quickly at WD12 pdf, the tables
are pretty much the same as what I started from – actually even more
undetermined (still many “?”)
So the changes I proposed (in red in the
RTF) depart indeed enough from the source tables to make it hard to identify
the original ;-)
Jacques
From: Marc Goodner
[mailto:mgoodner@microsoft.com]
Sent: Tuesday, May 02, 2006 5:14
PM
To: Durand, Jacques R.; Matthew
Lovett
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] More on i113
Actually, I’m looking
at this now and it looks like it is using an old version of the state table. I
can’t line this up against what is in WD12 at all.
From: Marc Goodner
[mailto:mgoodner@microsoft.com]
Sent: Tuesday, May 02, 2006 3:30
PM
To: Durand, Jacques R.; Matthew
Lovett
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] More on i113
Jacques,
Is this document the
proposed updates you note below?
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/document.php?document_id=17864
Download Document:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17864/state-tables-JD-3-diffs.rtf
From: Durand, Jacques
R. [mailto:JDurand@us.fujitsu.com]
Sent: Wednesday, April 26, 2006
1:02 PM
To: Matthew Lovett
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] More on i113
Matt:
Most proposed updates (except some in my
#2) still apply to your latest tables – will propose a sample of updated
tables.
Also propose the following:
- to not
" Fault a Fault", e.g. if RMS receives a Message Rollover Fault for
an unknown sequence,
it will
not complain back with "Unknown Sequence Fault".
- When
sequence expires: propose it closes rather than terminates: one must still be
able to query
it to
get a final Ack.
Thanks,
Jacques
From: Matthew Lovett
[mailto:MLOVETT@uk.ibm.com]
Sent: Wednesday, April 26, 2006
2:20 AM
To: Durand,
Jacques R.
Cc: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] More on i113
Hi Jacques,
Which version
of the tables are you working from? Issue i096 was recently accepted by the TC,
and includes an updated PDF for the tables. Unfortunately this issue hasn't
been folded into the current working draft.... so you should probably describe
your changes relative to i096 for now. My note to the TC that contained the
proposal for i096 contains both a PDF and the original open office doc, so it
should be quite easy to produce an annotated doc from there.
http://lists.oasis-open.org/archives/ws-rx/200604/msg00011.html
Thanks
Matt
"Durand, Jacques R."
<JDurand@us.fujitsu.com> wrote on 26/04/2006 04:15:10:
> While working on a more detailed proposal for
113, it appears to me
> that these tables need a bit more work than I
thought.
>
> (Again
I see these tables as more than just accessory: they are
> necessary to nail down corner cases, and are
ultimate ref material
> for developers.)
>
> In
addition to items currently in 113, I propose the following –
> depending on reactions on the mailing list, I
would update 113 appropriately:
>
> 1- As
mentioned before, for each one of the tables, events that may
> occur fall in two categories:
>
> (a)
those generated by the RM component (e.g. RMD generates and
> sends a Fault) and under full control of the
RM component,
> (b)
those “received” from outside , e.g. RMS gets a Fault message.
>
> for (a)
events, it is OK to use “N/A” for the non-relevant states
> (the RM component has control over generating
these events), but we
> cannot just use “N/A” for (b)
events, that the RM component must be
> prepared to handle in whatever state it is
in, even if such events
> occur when they shouldn’t. We need to
tell what is the effect of
> receiving (b) events in every state (even if
most of the times, sate
> remains the same). Can’t just brush it
off with N/A…
>
> 2-
There are still several TBD values in these tables – some of them
> are in particular related to the case where,
say the RMS, gets a
> fault like “Seq Closed Fault” or
“Seq Terminated Fault”, while RMS
> has not even closed or terminated the Seq
(mostly, a decision from
> RMD). I assume an RMS should update to
“closed” when getting a Seq
> Closed Fault, even if it has never sent
CloseSequence (like it does
> for termination). This has to appear in the
table.
> Another
case of questionable transition, is the “Elapse Expires
> duration” event. Should close IMO
instead of terminate, as RMS may
> want to be able to query a final Ack.
>
> 3-
there are events ( lines) in these tables that actually do not
> cause any state transition. E.g. in RMS
table: “new message”,
> “retransmit of unack message” ,
“SeqAck (non final)”, “Nack”. But it
> seems we are interested in reporting what
should the RMS behavior be
> for these in each current state. I’d
suggest to do this outside
> these state transition tables, e.g. in
another table where we
> consider specific events that do not cause
any transition, - but
> need to tell what should the RMS (RMD)
behavior be depending on the
> state it is in -, (kind of
“decision table”).
>
> Jacques
>
>