Re: Issue-6692 - Interim agreement draft

+1

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986

public-ws-resource-access-request@w3.org wrote on 07/13/2009 07:49:05 PM:

> Wu,
> 
> I apologize if I sound short-tempered, but I am finding this 
> conversation very frustrating. It seems to me that the concept I'm 
> trying to communicate is a very simple one, rooted in the basics of 
> XML extensibility and the SOAP framework, and I can't understand why
> I am unable to make myself clear to you.
> 
> The mechanics of an extension must be agreed upon by the parties 
> that wish to support that extension. This includes, among other 
> things, the QNames and XML types used to signal a request for that 
> extension. With regards to your list of possible ways to indicate a 
> request for "push with acks", the authors of "push with acks" have to 
pick one
> and use that.
> 
> For example, suppose we define that the request to enable "push with
> acks" is signaled by the inclusion of the "Acks" element from the 
> "http://www.freeble.org/evt-ext" namespace as a child of the /
> wse:Subscribe/wse:Delivery element. A Subscribe request with this 
> extension would look like the following:
> 
> <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:fre="http://www.freeble.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>
>         <fre:Acks>
>       </wse:Delivery>
>     </wse:Subscribe>
>   </s:Body>
> </s:Envelope>
> 
> An Event Source that supported "push with acks" (as defined by the 
> specification at "http://www.freeble.com/evt-ext") would recognize 
> the fre:Acks element and understand that this meant "I would like to
> enable the 'push with acks' extension on the Subscription that I am 
> requesting" because this is what the extension authors specified!
> 
> Meanwhile the following request:
> 
> <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/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>
>         <dev:PushWithAcks>
>       </wse:Delivery>
>     </wse:Subscribe>
>   </s:Body>
> </s:Envelope>
> 
> is, from the perspective of our Event Source, effectively not extended 
at all
> because our Event Source does not recognize the {http://
> www.smalldevices.org/evt-ext, PushWithAcks} QName and thus ignores it.
> 
> Except for the fact that unknown extensions are ignored instead of 
> generating a fault, this is absolutely no different than using @Mode
> . There is nothing magical about using a URI to signal extensions. 
> As an Event Source, either you understand/support an extension or 
> you don't. If you don't have the code to handle a particular 
> extension, the fact that you know how to parse @Mode doesn't help 
> you one little bit.
> 
> - gp
> 
> 
> On 7/13/2009 2:55 PM, Chou, Wu (Wu) wrote: 
> Gil,
> 
> Without a common semantic framework, e.g. WS-Policy, it is unclear 
> how the event source should determine the shape and semantics of a 
> QName. This may lead to a situation where different event sources 
> designate the composition of the same set of QNames with different 
> syntax and semantics, thereby creating interoperability issues for 
> the subscribers. 
> 
> For example, for Push delivery with ack, it can be represented as: 
> 1. <Push/><Ack/>
> 2. <Push><Ack/></Push>
> 3. <Ack/><Push/>
> 4. <Ack><Push/></Ack>
> 5. <myDelivery><Push><Ack/></Push></myDelivery>
> 6.  ? 
> 
> It is not clear if they are different or equivalent if without a 
> common semantic framework for their processing. This is not an issue
> in the original WS-Eventing, because there is only one way to 
> semantically parse Delivery/@Mode .
> 
> - Wu Chou.
> 
> From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
> Sent: Tuesday, July 07, 2009 8:00 PM
> To: Chou, Wu (Wu)
> Cc: Bob Freund; public-ws-resource-access@w3.org
> Subject: Re: Issue-6692 - Interim agreement draft

> Wu,
> 
> Please describe in detail the interoperability problems that will 
> result if we allow "arbitrary" and "open ended" XML extensions.
> 
> - gp
> 
> On 7/7/2009 2:52 PM, Chou, Wu (Wu) wrote: 
> Bob,
> 
> Our understanding is: the consensus at the F2F meeting is to replace
> the mode uri and use Qnames to define the delivery mechanism. It is 
> a refactor or a replacement of the original simple mode uri for the 
> ease of composition. It is not to allow open ended xml to define the
> delivery mechanism and lump into other extensions under xs:any.
> 
> By allowing that, we are making a simple replacement of mode uri 
> arbitrarily complex. 
> 
> Moreover, when a Qname is used to specify a requirement, as it is 
> used here for defining delivery mechanism, it is using the WS-Policy
> semantics of an assertion. We will show in our proposal that this 
> can be described using non-nested policy assertions, but do not 
> require a full implementation of WS-Policy and still using simple 
> Qname matching, since the list of Qnames used here, as replacement 
> of mode uri, is not nested.
> 
> An arbitrary open ended xml has no uniquely defined semantic 
> meaning, and therefore, it will introduce interoperability problem 
> unless its semantic interpretation is specified as in Policy. 
> 
> We are seriously concerned the consequence to generalize from a list
> of non-nested Qnames into an arbitrary open ended xml which has no 
> uniquely defined semantics.
> 
> - Wu Chou.
> 
> From: Chou, Wu (Wu) 
> Sent: Monday, July 06, 2009 8:09 PM
> To: Bob Freund
> Cc: 'public-ws-resource-access@w3.org'
> Subject: Re: Issue-6692 - Interim agreement draft

> Bob,
> Glad to see some good progress being made. We would like to add a 
> further work issue to your list:
> 4) Using Policy inside the delivery element to describe delivery 
extensions.
> Rationale: If any xml under xs:any is allowed as extension elements 
> to change the default Push delivery, how to uniquely determine the 
> semantics and behavior represented by these extension elements in a 
> light weight and computational efficient way will become an acute issue.
> In addition, event source needs a way to advertise the allowed 
> delivery extensions/combinations. And if an event subscription is 
> accepted, the event subscriber should know exactly what delivery 
> mechanism is used by the event source to send event notification.
> After some study and comparison, we would like to propose using 
> Policy inside the delivery element to address this issue. We will 
> submit a detailed proposal for the WG to discuss. This proposal will
> cut across the current TBD topics 1-3 and as a result may need to be
> handled before the others.
> Many thanks,
> - Wu Chou.
> Wu Chou, IEEE Fellow, Ph.D. | Director |Avaya Labs Research | AVAYA | 
> 233 Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 | Voice/Fax: 
> 908-696-5198 / 908-696-5401 | wuchou@avaya.com 
> From: Bob Freund <bob.freund@hitachisoftware.com> 
> Date: Mon, 6 Jul 2009 13:43:03 -0400
> Message-Id: <FDF27172-5127-4D9C-B7BC-B2CAC4D83697@hitachisoftware.com> 
> To: public-ws-resource-access@w3.org 
> The following is a draft that incorporates the current state of 
> agreement on Issue-6692.
> Note that within the document there are several areas marked "TBD" 
> which represent further aspects that are yet to be thrashed out.
> This version has been reviewed by both Microsoft and IBM and both are 
> agreeable as to it use as the reference for further issue negotiation.
> The summary of further work needed is :
> 1) Fault behavior relating to delivery extensions as the original 
> fault definition related to @mode
> 2) extension negotiation behavior if any since the original @mode 
> fault optional detail element was thought to provide some negotiation 
> mechanism albeit unreliable
> 3) Use of the word "Push" rather than simply the one default method of 
> notification delivery.  Nothing particularly distinguishes "Push" from 
> normal asynchronous delivery and its use in th text is infrequent
> 
> I would be interested in discussing this on the next call as well as 
> the opinion of folks as to the potential division of this issue into 
> three additional issues as represented by the points above.
> thanks
> -bob
> application/msword attachment: wseventing-6692-9-1.doc 
> application/pkcs7-signature attachment: smime.p7s