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

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