RE: Extension Handling 101: Example 4

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>

Where in the spec can I see this guarantee defined?
Note a) and b) could be compatible or incompatible extensions.

What about between implementations?
Is a) guaranteed to produce the same subscription or fault across implementations of Eventing?

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.

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