W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > January 2010

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

From: Li, Li (Li) <lli5@avaya.com>
Date: Wed, 27 Jan 2010 11:11:45 -0500
Message-ID: <7DC6C0F0E8D7C74FB4E1E73CC371280A01505AFE@300813ANEX2.global.avaya.com>
To: "Gilbert Pilz" <gilbert.pilz@oracle.com>
Cc: <public-ws-resource-access@w3.org>, "Chou, Wu (Wu)" <wuchou@avaya.com>


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


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



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



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: 

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

Received on Wednesday, 27 January 2010 16:12:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:54 UTC