RE: Extension Handling 101: Example 4

Geoff,

I'd ask this question.... will this:
<Subscribe>
  <wse:Delivery>...</wse:Delivery>
  <X/>
  <Y/>
</Subscribe>

always produce the same results as this:
<Subscribe>
  <wse:Delivery>...</wse:Delivery>
  <Y/>
  <X/>
</Subscribe>

Or will:
<Subscribe x="foo" y="bar">
  <wse:Delivery>...</wse:Delivery>
</Subscribe>

always produce the same result as this:
<Subscribe y="bar" x="foo">
  <wse:Delivery>...</wse:Delivery>
</Subscribe>

The question you're asking isn't Delivery specific and applies to all WS* 
specs and all extension points (including soap headers).

I'm having a hard time understanding why we're trying to add special 
semantics and rules for this one extension point when I can't think of any 
other WS* spec that has ever had a need to do so.  Why would WS-Eventing 
need to change the normal extension processing model? 

If keeping "Delivery" around is causing so much trouble (its just a 
wrapper for an xs:any) then perhaps we made the wrong choice by keeping 
it.  Clearly its history and implied "specialness" is causing some people 
to forget everything we'd done in the past w.r.t. extensions.

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.



Geoff Bullen <Geoff.Bullen@microsoft.com> 
Sent by: public-ws-resource-access-request@w3.org
07/07/2009 11:46 PM

To
Gilbert Pilz <gilbert.pilz@oracle.com>, "public-ws-resource-access@w3.org" 
<public-ws-resource-access@w3.org>
cc

Subject
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"
            xmlns:wsa="http://www.w3.org/2005/08/addressing"
            xmlns:wse="http://www.w3.org/2009/02/ws-evt"
            xmlns:frq="http://www.refractory.org/timeDilation"
            xmlns:dev="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"
            xmlns:wsa="http://www.w3.org/2005/08/addressing"
            xmlns:wse="http://www.w3.org/2009/02/ws-evt"
            xmlns:dev="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