Re: Extension Handling 101: Example 4

Comments inline . . .

On 7/7/2009 8:46 PM, Geoff Bullen wrote:
>
> Hi Gil,
>
> Thanks for these examples.  Can I share one with you please?
>
>  
>
> Let’s look at order of processing.
>
> Will this:
>
> a)
>
> <wse:Delivery>
>
>    <X />
>
>    <Y />
>
> </wse:Delivery>
>
> Always be guaranteed to produce the same results (subscription or 
> fault) as:
>
> b)
>
> <wse:Delivery>
>
>    <Y />
>
>    <X />
>
> </wse:Delivery>
>
It depends upon how the extensions indicated by <X> and <Y> are 
specified. If either extension-X or extension-Y are specified to take 
each other into account, it is possible for the order to be significant 
and a) and b) could produce different results. To the best of my 
knowledge, there are no existing extensions to any WS-* specifications 
that work this way, but it's possible.
>
>  
>
> Where in the spec can I see this guarantee defined?
>
> Note a) and b) could be compatible or incompatible extensions.
>
You can't see this behavior specified anywhere in the WS-Eventing spec 
nor should you because *it has nothing to do with WS-Eventing*, it is up 
to the authors of the extensions in question.

I've said this before and I'll say it again (and again, and again . . . 
until people understand); within the extension framework defined by 
WS-Eventing (extension points defined in XML Schema, ignore unknown 
extensions, etc.) you cannot limit what extension authors are allowed to 
do. Extension points are an admission to the world that "we don't know 
everything"; there are use cases for WS-Eventing that we simply can't 
imagine. Given this admission it is illogical to try and limit how 
extensions are expressed (e.g. you must use a single QName with no child 
elements and no more than 3 attributes) because, since we don't know 
everything, we have no way of knowing that these limitations won't 
impact the ability to implement an extension (e.g. what if you really 
needed child elements or 4 attributes to implement the extension?)
>
>  
>
> What about between implementations?
>
> Is a) guaranteed to produce the same subscription or fault across 
> implementations of Eventing?
>
Again, this has nothing to do with WS-Eventing and everything to do with 
the specifications of extension-X and extension-Y.
>
>  
>
> Note that in the original spec using the mode attribute to define a 
> new mode MODE_X_Y would allow such a guarantee of interoperability.
>
MODE_X_Y also required some third-party to define and bless MODE_X_Y as 
the combination of extension-X and extension-Y. This extension model is 
appropriate for industry vertical profiles like WS-Man but completely 
inappropriate for general purpose infrastructure specifications like 
WS-Eventing.
>
>  
>
> Thanks,
>
> Geoff
>
>  
>
> *From:* public-ws-resource-access-request@w3.org 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of 
> *Gilbert Pilz
> *Sent:* Tuesday, July 07, 2009 6:25 PM
> *To:* public-ws-resource-access@w3.org
> *Subject:* Extension Handling 101: Example 4
>
>  
>
> OK, here it is. The extended Subscribe request that our mother always 
> warned us about, Example 4:
>
> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" <http://www.w3.org/2003/05/soap-envelope>
>             xmlns:wsa="http://www.w3.org/2005/08/addressing" <http://www.w3.org/2005/08/addressing>
>             xmlns:wse="http://www.w3.org/2009/02/ws-evt" <http://www.w3.org/2009/02/ws-evt>
>             xmlns:frq="http://www.refractory.org/timeDilation" <http://www.refractory.org/timeDilation>
>             xmlns:dev="http://www.smalldevices.org/evt-ext" <http://www.smalldevices.org/evt-ext>>
>   <s:Header>
>     <wsa:Action>http://www.w3.org/2009/02/ws-evt/Subscribe</wsa:Action>
>     . . .
>   </s:Header>
>   <s:Body>
>     <wse:Subscribe>
>       <wse:Delivery>
>         <wse:NotifyTo>
>           <wsa:Address>http://www.example.com/MyEventSink/OnStormWarning</wsa:Address>
>         </wse:NotifyTo>
> *        <frq:Dilate>*
> *          <frq:TimeScale useRelative="true">*
> *            <frq:PhaseShift>-73.243</frq:PhaseShift>*
> *          </frq>*
> *          <frq:Margin>2009-07-07T15:27:26-0700</frq:Margin>*
> *        </frq:Dilate>*
>         *<dev:Pauseable>*
> *          <dev:Duration>P3H</dev:Duration>*
> *        </dev:Pauseable>*
>       </wse:Delivery>
>     </wse:Subscribe>
>   </s:Body>
> </s:Envelope>
>
> It bends the mind! How can we possibly figure out how frq:Dilate and 
> dev:Pauseable are supposed to interact? Will the time dilation shorten 
> or lengthen the pause duration and, if so, by how much? But wait! We 
> don't support frq:Dilate. Using the "power of ignorability" granted to 
> us by the WS-Eventing spec, we can (nay SHOULD!) act as if frq:Dilate 
> element *wasn't even there*! In which case we can create a pauseable 
> Subscription (because we support that) and respond as we did in Example 3:
>
> <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" <http://www.w3.org/2003/05/soap-envelope>
>             xmlns:wsa="http://www.w3.org/2005/08/addressing" <http://www.w3.org/2005/08/addressing>
>             xmlns:wse="http://www.w3.org/2009/02/ws-evt" <http://www.w3.org/2009/02/ws-evt>
>             xmlns:dev="http://www.smalldevices.org/evt-ext" <http://www.smalldevices.org/evt-ext>>
>  <s:Header>
>     <wsa:Action>http://www.w3.org/2009/02/ws-evt/SubscribeResponse</wsa:Action>
>     . . .
>   </s:Header>
>   <s:Body>
>     <wse:SubscribeResponse>
>       <wse:SubscriptionManager>
>         <wsa:Address>
>           http://www.example.org/oceanwatch/SubscriptionManager
>         </wsa:Address>
>       </wse:SubscriptionManager>
> *      <dev:Pauseable>*
> *        <dev:Duration>P1H</dev:Duration>*
> *      </dev:Pauseable>*
>     </wse:SubscribeResponse>
>   </s:Body>
> </s:Envelope>
>
> And so concludes Example 4.
>
> - gp
>