Re: draft 3 of WS-Eventing state tables

I don't think these tables define "internal states" so much as 
"expectation states" with regards to the messages that the consumer and 
the provider can expect to send and receive. For example, an Event 
Source cannot expect to send a successful wse:Unsubscribe message for a 
Subscription unless that Subscription is in the "Created" state.

The information in these tables is supposed to duplicate the information 
that is contained in the normative text of the spec but present it in a 
manner that can be easily consumed by developers. A desired side-effect 
of the process of constructing these state tables is to flush out any 
areas where the spec is unclear about the effects of particular 
messages. For example, if a Subscriber sends a wse:Unsubscribe message 
and receives a wse:EventSourceUnableToProcess fault in response, what is 
the state of the Subscription in question? Again, by "state" I mean 
"What messages can the Subscriber/Event Sink expect to send and receive 
in relation to this Subscription?" Can it assume that Notifications for 
this Subscription will continue to be transmitted by the Event Source?

- gp

On 9/16/2009 7:34 AM, Li, Li (Li) wrote:
> Gil,
>
> Thanks for updating the tables. As I understood it, the purpose of this
> proposal is to enhance interoperability between WS-E web services
> without getting into any implementation details. Since these tables
> define internal states of SOAP endpoints that are apparently outsides
> the scope of web service interfaces, how do you expect these tables be
> followed by implementations? In other words, what information in these
> tables is not already in or implied by the WS-E spec?
>
> Thanks,
>
> Li Li
>  
>
>
>