RE: issue 6435: v7 of the WS-Eventing state tables

Here are some comments about the state tables as requested by Bob in
yesterday's discussion. 

 

We agree that the states are for a subscription, not the processes. To
clarify this point, we can:

i) Modify "Notes on Reading the State Tables" as follows:

* The states are for a subscription and are represented as columns...

* Actions are performed on the subscription and are represented as
rows...

 

ii) Rename table heading and state "idle" to more proper names as they
refer to the states of a process (can a subscription be idle?)

 

iii) clarify the meaning of the empty cells: are they undefined or
illegal?

 

Thanks.

 

Li  

________________________________

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Wednesday, January 27, 2010 1:28 PM
To: Li, Li (Li)
Cc: public-ws-resource-access@w3.org; Chou, Wu (Wu)
Subject: Re: issue 6435: v7 of the WS-Eventing state tables

 

I disagree with your assertion that we don't need two tables. One of the
things these tables highlight is that a subscription (or enumeration) is
an instance of shared state between the client and the server, yet the
client and the server may have different notions about the state of a
subscription.

- gp

On 1/27/2010 8:11 AM, Li, Li (Li) wrote: 

Gil,

 

Thanks for the clarification. I think the table title and some state
name confused me a bit.

 

Now that I understand what you did, I think the states can be
simplified. Based on your table, I drew a UML state chart that has only
two states for the subscription, basically merging the "idle" and "end"
states into a "null" state.

 

I also feel that we don't need two tables (one for client and one for
server), as one is sufficient for the purpose you stated in the "Notes
on Reading the State Tables".

 

Though I am used to diagrams, I am ok with table representations as
well. 

 

For your reference, I am attaching a word file with the state chart.

 

Best,

Li Li  

________________________________

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Wednesday, January 27, 2010 2:38 AM
To: Li, Li (Li)
Cc: public-ws-resource-access@w3.org; Chou, Wu (Wu)
Subject: Re: issue 6435: v7 of the WS-Eventing state tables

 

Li,

You are correct, the state tables define the states and transitions
during the lifetime of single instance of a subscription (or an
enumeration in WS-Enum's case). Would it help if we labeled the columns
as "Subscription States" ("Enumeration States"), or do you think
something more explicit needs to be said about this?

- gp

On 1/26/2010 11:57 AM, Li, Li (Li) wrote: 

Gil,
 
Thanks for the update. After reading the tables and the notes, I wasn't
sure whose states we are describing. It appears that you are describing
the states of the processes, e.g. subscriber/sink or event
source/manager. However, this is difficult because each of these
processes can handle many subscriptions simultaneously. As the result,
the state tables have many empty cells that are undefined.
 
So what you did is actually defining the states of those processes
regarding one subscription. If this is the case, I think it is better to
directly define the state transitions for the subscription, instead of
the states of the processes. 
 
I think the information in the current tables can be reused.
 
This would lead to a more concise and precise description of the
behavior of the processes that developers care about.
 
Thanks.
 
Li Li