RE: Issues 6425 and 6436 State Tables comments

First of all, thanks to Gil for putting together the state tables. It is not an easy task.



I have some comments on the tables.



1.  On all WS-Enumeration and WS-Eventing tables: Merge Idle and End states; name of the state can be "None".


2.  WS-Enumeration Consumer table and WS-Eventing Sink table:

a.  Remove timer/expiration row since the trigger is manifested via need to send a Unsubscribe or Release msg.

b.  Consider a dedicated row for each fault message. This will capture under what circumstances fault are generated.


3.  WS-Enumeration Consumer table:

a.  Release Fault on Releasing should not go to active. The Enumeration specification states that the enumeration terminates when the consumer sends a Release request.

b.  Add TimedOut fault [msg] row.

c.  RenewResponse [msg]: Remove moving from End state to Active. If the consumer has decided that the enumeration has ended, it shouldn't change this assumption based on subsequent messages.

d.  "Renewing', "Getting Status", "Releasing" states makes it harder to describe the behavior of an asynchronous client. Suggest removing them.

e.  The table [1] includes faults as separate events and also removes the states described in #3d above.

§  [1] doesn't include the actions and decisions in the cells, only the state transitions. The action and decision functions should be added back once we agree on the table shape.

4.  WS-Enumeration data source table:

a.  The table [2] describes the state transitions.

b.  Suggest adding Pull timeout event. It is useful to show that this event does not invalidate the enumeration context.



[1] WS-Enumeration consumer state transitions


Event

None

Creating

Active

Invalid

Enumerate [app]

[Creating]

N/A

N/A

N/A

EnumerateResponse [msg]

N/A

[Active] or [Invalid]

N/A

N/A

Pull [app]

N/A

N/A

[Active]

N/A

PullResponse [msg]

N/A

N/A

[Active] or [Invalid]

[Invalid]

Renew [app]

N/A

N/A

[Active]

N/A

RenewResponse [msg]

N/A

N/A

[Active]

[Invalid]

GetStatus [app]

N/A

N/A

[Active]

N/A

GetStatusResponse [msg]

N/A

N/A

[Active]

[Invalid]

Release [app]

N/A

N/A

[Invalid]

N/A

ReleaseResponse [msg]

N/A

N/A

N/A

[Invalid]

EnumerationEnd [msg]

N/A

[Invalid]

[Invalid]

[Invalid]

InvalidExpirationTime [msg] 4.1

N/A

[Invalid]

N/A

[Invalid]

ExpirationTimeExceeded [msg] 4.2

N/A

[Invalid]

N/A

[Invalid]

UnsuportedExpirationTime [msg] 4.3

N/A

[Invalid]

N/A

[Invalid]

FilteringNotSupported [msg] 4.4

N/A

[Invalid]

N/A

[Invalid]

FilterDialectRequestedUnavailable [msg] 4.5

N/A

[Invalid]

N/A

[Invalid]

CannotProcessFilter [msg] 4.6

N/A

[Invalid]

N/A

[Invalid]

InvalidEnumerationContext [msg] 4.7

N/A

N/A

[Invalid]

[Invalid]

TimedOut [msg] 4.8

N/A

[Invalid]

[Active]

[Invalid]

UnusableEPR [msg] 4.9

N/A

[Invalid]

N/A

[Invalid]




[2] WS-Enumeration data source state transitions


Event

None

Active

Invalid

Enumerate [msg]

[Active] or [None]

N/A

N/A

Pull [msg]

N/A

[Active] or [Invalid]

[Invalid]

Renew [msg]

N/A

[Active] or [Invalid]

[Invalid]

GetStatus [msg]

N/A

[Active]

[Invalid]

Release [msg]

N/A

[Invalid]

[Invalid]

Pull Timeout [event]

N/A

[Active]

N/A

Invalidation [event]

N/A

[Invalid]

N/A




-----Original Message-----
From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Bob Freund
Sent: Thursday, January 28, 2010 6:02 AM
To: public-ws-resource-access@w3.org
Subject: Issues 6425 and 6436 State Tables comments



1. Each actor requires its own table

2. Each actor is presented with full set of messages defined under the protocol and the next state is indicated as well as actions performed and reference to spec

3. Where spec is silent, no entry is made so that the table reflects current state of the spec

4. In the case of eventing, the subscription seems not to be an actor, but represents state storage for all actors



consequently as an example of server-side states for eventing, the existing proposal can be corrected by dividing it into two sets of columns, one set representing the event source, and one set representing the subscription manager.

as for the entity we describe as a subscription, since it represents state storage, it can be thought of as being created when a valid subscribe request is processed and destroyed when a subscription ends.  It seems that there are two states for each of these actors.

a) subscription exists, and

b) subscription does not exist