RE: WS-Eventing optionality analysis

Hi Gil,

Some minor nits:


·       Shouldn’t wse:SubscriptionEnd/wse:Reason element be colored Blue color instead of Red, since a subscriber is expected to process it, assuming of course the subscriber supports wse:EndTo?

·       The phrase “Optionality: linked to the use of UnsubscribeResponse” should be “Optionality: linked to the use of Unsubscribe”.

Thanks.

From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Gilbert Pilz
Sent: Tuesday, September 21, 2010 3:45 PM
To: public-ws-resource-access@w3.org
Subject: WS-Eventing optionality analysis

Attached is an analysis of the optionality of the various operations/messages and features in WS-Eventing. I'm not sure if this format is the best for displaying this information. I tried to color code things: black is required, blue is required for one party but not another, red is optional for both parties. Sub-elements/sub-features are scoped to the optionality of there containing element/feature. For example, event sources are required to support expiration values using xs:duration iff they support wse:Expires, but subscribers may elect to use xs:dateTime values - so xs:duration is blue (required for event source, optional for subscriber) scoped by a red element/feature (wse:Expires).

If anyone has a better suggestion on how to display this info, please speak up.

One issue that writing this analysis brought up is the granularity of options. In the case of WS-Eventing this only impacts subscription expiration, but it might impact the other spec differently. For WS-Eventing the question is, "If you are an event source that supports wse:Subscribe/wse:Expires are your subscription manager therefor required to support wse:Renew/wse:Expires?" Put another way, "Can I have a subscription manager that supports wse:Renew/wse:Expires even though my event source doesn't support wse:Subscribe/wse:Expires?"

~ gp