Re: Enumeration state tables

Comments inline

On 9/27/2009 12:54 PM, Doug Davis wrote:
>
> Couple of comments:
> 1 - if we're going to do this then I'd like to suggest that we get 
> some version of these into the spec sooner rather than later.  Having 
> this in the spec sooner will people more time to review it - including 
> non-WG members.
<gp>I would like that as well.</gp>
> 2 - We probably need an [End] state - in both tables
<gp>Why? As there is no state you can progress to after entering the 
[End] state, it seemed to me that there was no need to include it in the 
tables.</gp>
> 3 - on the consumer side - when we're in states like "Getting Status", 
> can't we also do a Renew?  No need to serialize things, right?
<gp>Correct. I didn't mean to imply that we should serialize operations 
on the enumeration.</gp>
> 4 - do we need to say what happens if a GetStatusResponse comes in but 
> we're not in the "Getting Status" state?  if not, then I'm not sure we 
> need the "Getting Status" state.  If fact, this state could cause 
> confusion because it implies you can't do a Renew while in that state.
<gp>If the consumer receives a GetStatusResponse when it has not sent a 
GetStatus message (an event that would have caused it to enter the 
"Getting Status" state) that would seem to indicate that there is 
something wrong with the implementation of the source. It's true that a 
consumer could simultaneously be in both the "Getting Status" and the 
"Renewing" states. I'm not sure how to handle this other than to note it 
at the end of  the table.</gp>
> 5 - consumer: Expiration while in the Renewing state.... this one is 
> interesting.  From the consumer's point of view, if they get back a 
> fault from the renew then they're not back in "Created" state, they 
> should be in "End" state.
<gp>To be clear, "Expiration" is a "timer" not a "msg" event. That is to 
say, it is triggered by an internal timer, not the arrival of a message. 
My thinking was that, if the consumer sends a Renew message then, while 
awaiting the RenewResponse its timer goes off, it should continue to 
wait for the response since that will tell it unequivocally what the 
state of the enumeration is.
> 6 - on data source, the Pull request should probably have the if-stmt 
> only on the sending of the EndOfSequence element since it could appear 
> _with_ data too.
<gp>That's what I meant to communicate. Feel free to modify the text as 
you see fit.</gp>
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> The more I'm around some people, the more I like my dog.
>
>
> *Gilbert Pilz <gilbert.pilz@oracle.com>*
> Sent by: public-ws-resource-access-request@w3.org
>
> 09/11/2009 07:31 PM
>
> 	
> To
> 	"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
> cc
> 	
> Subject
> 	Enumeration state tables
>
>
>
> 	
>
>
>
>
>
> Attached is the first draft of the state tables for WS-Enumeration. 
> Overall this was pretty straightforward. The one thing I'm not sure 
> about is, when the Consumer is in the "Releasing" state (having sent a 
> wsen:Release request) and it receives a fault that is not 
> wsen:InvalidEnumerationContext it seems that the Consumer has no 
> choice but to assume the request wasn't processed and the Enumeration 
> is still in the "Created" state.
>
> While working on these state tables it occurred to me that the issues 
> around expiration representation and expiration negotiation that we 
> are discussing for WS-Eventing are also issues for WS-Enumeration.
>
> - gp[attachment "Enumeration-State-Tables-v1.doc" deleted by Doug 
> Davis/Raleigh/IBM]