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