- From: Doug Davis <dug@us.ibm.com>
- Date: Wed, 8 Jul 2009 12:15:42 -0400
- To: Geoff Bullen <Geoff.Bullen@microsoft.com>
- Cc: Gilbert Pilz <gilbert.pilz@oracle.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, "public-ws-resource-access-request@w3.org" <public-ws-resource-access-request@w3.org>
- Message-ID: <OF7C0E20E9.65201056-ON852575ED.005878C3-852575ED.005956E4@us.ibm.com>
Geoff wrote: ... > A. The limitation we are discussing concerns the processing > order of the ?Set of QNames? (extension elements) we decided to use > in 3). It does seem to be a legitimate limitation in interoperability. Please provide an example where 'order' matters and is something that WS-E needs to worry about instead of the extension itself. > B. The limitation exists with or without the presence of the > Delivery element, which is orthogonal to this discussion. No its very important since having a new extension processing mechanism just for one extension point in WS-E introduces an inconsistency that will be hard to explain. > C. This issue was raised by Wu during the con call on Tuesday, > but I think was confused with the issue around the definition of a > Push QName ? they are separate issues. > D. Wu suggested we should consider a different solution to 2) > based around the Policy framework, rather than the extension > framework proposed in 3). > E. Both the current solution 3) and Wu?s proposed policy-based > solution have pros and cons. > F. In order to move forwards here, we need to discuss the > limitation in solution 3) openly and in an unbiased way in order to > decide how important the limitation is and if it causes us to in any > way reconsider the decision taken in 3) above. you first need to show this limitation in a real concrete way because I just don't see it. Any limitiation you claim to exist here would apply to all extensions. Trying to say that Delivery is 'special' requires some proof because any scenario you come up with will probably just as easily apply to any extension point. > One observation I would make is this: > To date, the extension framework has been successful in providing a > mechanism for adding composable functionality where that > functionality is largely independent in nature. Each extension > affects the SOAP message (reliable, secure, ?) but extensions do not > tend to affect each other. In this case extensions (Pull, Ack, > Pause, ?) can have an effect on each other (Ack may only work with > Push, not Pull). This may be the first time that such side effects > have to be taken into account. Sorry - but I don't buy the premise that SOAP itself is broken or that no two extensions have ever been written to interact with each other. E.g. WSA (an extension) interacts with Tx, RM just fine. MC (ie. pull) works just fine with WSA, RM... WS-Eventing is just not that special :-) What's different here is that people keep trying to make it special. Why? I dunno. > --Geoff > > > From: Doug Davis [mailto:dug@us.ibm.com] > Sent: Wednesday, July 08, 2009 5:18 AM > To: Geoff Bullen > Cc: Gilbert Pilz; public-ws-resource-access@w3.org; public-ws- > resource-access-request@w3.org > Subject: 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
Received on Wednesday, 8 July 2009 16:16:39 UTC