Re: WS-Eventing optionality analysis

Been thinking about this and I actually think the inconsistency is some 
place else in the doc.  If you look at how the Subscribe operation is 
defined, it basically says this - w.r.t. Expires:
- the Expires element is optional for both the subscriber and the event 
source
- an event source is not required to support the Expires element (note, it 
says 'element' not the expiry feature)
- the absence of the Expires element means that the subscription has an 
indefinite expiration time
- an Expires element with a value of PT0S also means indefinite expiration

Note that the absence of the Expires element doesn't mean that the 
Subscription Manager doesn't have to support the notion of expiry.  In 
fact, the spec says the exact opposite when it says that there is a 
default value for Expires of 'indefinite':
        If this element is not present, the implied default expiration 
time is indefinite. 

This means that Subscription Managers do in fact need to support the 
notion of expiry, its just that in some cases they may only support the 
'indefinite' or PT0S value.  Which is fine.  But this is where the 
inconsistency lies.

The spec right now, mistakenly, gives the impression that the feature of 
expiry is optional for the Subscription Manager by making the Expires 
element option for it to support.  But, this isn't true - the spec makes 
it clear that even w/o the presence of the Expires element the expiry 
feature gets a default value (PT0S) - so while the Expires element may be 
optional, the feature behind it is not.  If this isn't clear, think of it 
this way:  what is the semantic difference between a Subscribe w/o an 
Expires element and a Subscribe with an Expires element that has a PT0S 
value?  W.r.t. the expiry feature there is no difference.  This is why I 
believe that presence or absence of the Expires element has no relation to 
whether expiry itself is supported - in short because it is always 
supported.

Now, in practice someone may choose to look at this and say that absence 
of Expires (or even Expires + PT0S) is the equivalent of not supporting 
expiry because it'll never expire.  And that is true from an "end results" 
type of perspective, but from a spec perspective these are very different 
things.  How someone chooses to implement a PT0S value is up to them. 
Whether they set a timeout value to a very large number or whether they 
just never check for a timeout at all is an implementation choice.  But 
either way, from an on-the-wire/spec perspective they are in fact 
supporting Expires with a value of PT0S - as the spec says.

So, in the end I think the inconsistency is around the notion of allowing 
an Event Source (or Subscription Manager) to claim that it doesn't support 
the Expires element - its silly to not support the element when it must 
support the feature behind the element.  Or said another way, its silly to 
allow someone to imply a value of PT0S but then fault them when they try 
to be explicit about it.  We should remove sentences like:
If the event source does not support the wse:Expires element being present 
in a Subscribe request message then a wse:ExpiresNotSupported fault MUST 
be generated.
And if people don't want to support anything but indefinite expiry times 
then they should only allow Subscribes (or Renews) with either no Expires 
element or an Expires element with a value of PT0S.  This is related to 
the issue I opened earlier today [1].  If we remove the above sentence and 
tweak the policy then we can remove the wse:ExpiresNotSupported fault too.

I don't think this would change the semantics of the spec at all and would 
clear up any inconsistency around this point.  Its also consistent with 
the Member Submission too which didn't allow an Event Source to reject a 
Subscribe solely due to the presence of the Expires element.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10960

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/30/2010 02:59 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
Re: WS-Eventing optionality analysis






I don't know if this point has ever been discussed before, but it seems to 
me that there is an inconsistency in the optionality of elements and 
operations in WS-Eventing. Specifically Event Sources/Subscription 
Managers are not required to support subscription expiration, yet 
Subscription Managers are required to support the Renew operation. Since 
the function of the Renew operation is to update the expiration for a 
subscription, by definition this operation has to be a no-op for 
implementations that don't support any form of expiration.

Did we have a reason for doing this, or are we just stupid?

~ gp

On 9/27/2010 7:03 AM, Doug Davis wrote: 

Nice catch on the Expires issue.  Seems to me that it would be good for 
the spec to mandate that whatever choice the event source makes that it be 
consistent across all operations.  Sounds like a new issues to me. 

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/21/2010 06:45 PM 


To
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org> 
cc

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[attachment "ws-eventing-optionality-analysis.odt" deleted by Doug 
Davis/Raleigh/IBM]