Re: Issue-6692 - Interim agreement draft

You still haven't answered the question "Why does WS-Eventing's 
extensibility model have to be different from all other WS-* specs?"

- gp

On 7/17/2009 7:03 AM, Chou, Wu (Wu) wrote:
> Gil,
>
> Please see my comments in line.
>
>  - Wu Chou.
>
> ------------------------------------------------------------------------
>
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Wednesday, July 15, 2009 3:24 PM
> *To:* Chou, Wu (Wu)
> *Subject:* Re: Issue-6692 - Interim agreement draft
>
> Who said the QName is treated as an assertion,  and what difference 
> would that make in any case?  
>
> **(Wu: Check ws-policy to see what the difference it makes****)** 
>
> An Event Source either understands/recognizes the QName of the 
> extension (or assertion if you prefer) *or it does not!* It's a binary 
> distinction. This is software we are talking about; there are no 
> "close misses".  
>
> **(Wu: This is so true that ****it is not the concern here. The issue 
> is the (policy) expression semantics formed by these Qnames 
> (assertions))**
>
>  An Event Source that understands/recognizes "sdev:PushWithAcks" but 
> doesn't recognize "fsv:AckNotifications" doesn't know or care that, to 
> a human, they seem like they might mean the same thing.  
>
> **(Wu: Couldn't agree more, as stated in my another email on this 
> thread that they are totally different from the Qnames perspective.)**
>
>  I have the hardest time understanding your model because it seems the 
> me that you imagine that there is a human being in the loop looking at 
> every Subscribe request and attempting to interpret the extension 
> elements.  
>
> **(Wu: I am using ws-policy model, and it will really help if you can 
> take a look from that angle. ****I don't imagine ws-policy requires 
> t****here is a human being in the loop.)**
>
> It would be really helpful if you could describe, at a high level, the 
> exact sequence of steps you think should happen during extension 
> negotiation. 
>
> **(Wu: It will be covered in our  proposal to the WG, in which such a 
> high level view is described during extension negotiation.)**
>
> - gp
>
> ------------------------------------------------------------------------
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Wednesday, July 15, 2009 3:24 PM
> *To:* Chou, Wu (Wu)
> *Subject:* Re: Issue-6692 - Interim agreement draft
>
> Who said the QName is treated as an assertion, and what difference 
> would that make in any case? An Event Source either 
> understands/recognizes the QName of the extension (or assertion if you 
> prefer) *or it does not!* It's a binary distinction. This is software 
> we are talking about; there are no "close misses". An Event Source 
> that understands/recognizes "sdev:PushWithAcks" but doesn't recognize 
> "fsv:AckNotifications" doesn't know or care that, to a human, they 
> seem like they might mean the same thing. I have the hardest time 
> understanding your model because it seems the me that you imagine that 
> there is a human being in the loop looking at every Subscribe request 
> and attempting to interpret the extension elements. It would be really 
> helpful if you could describe, at a high level, the exact sequence of 
> steps you think should happen during extension negotiation.
>
> - gp
>
> On 7/15/2009 11:20 AM, Chou, Wu (Wu) wrote:
>> If a Qname is treated as an assertion (assertion is defined as a 
>> Qname), then the Qname composition semantics is equivalent to policy 
>> expression semantics. Check WS-Policy or its tutorial Primer for more 
>> information.
>>  
>> Have fun,
>>  
>> - Wu Chou
>>
>> ------------------------------------------------------------------------
>> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
>> *Sent:* Tuesday, July 14, 2009 6:05 PM
>> *To:* Chou, Wu (Wu)
>> *Cc:* Doug Davis; Bob Freund; public-ws-resource-access@w3.org; 
>> public-ws-resource-access-request@w3.org
>> *Subject:* Re: Issue-6692 - Interim agreement draft
>>
>> Wu,
>>
>> I sorry, but I don't have the faintest idea what you mean by "QName 
>> composition semantics". Please define your terms.
>>
>> - gp
>>
>> On 7/14/2009 12:18 PM, Chou, Wu (Wu) wrote:
>>> Doug,
>>>  
>>> This is the issue. If just from Qnames, 
>>> "Delivery/@Mode=".../PushWithAck" , 
>>> Delivery/@Mode=".../MyPushWithAck" , 
>>> Delivery/@Mode=".../WusPushWithAck" " are not the same. But  in 
>>> terms of  the Qname composition semantics, they can be interpreted 
>>> as the same or not the same depending on the semantic model being used.
>>> To determine the semantics of Qname composition, just knowing the 
>>> definition of each individual Qname is not enough. Otherwise 
>>> WS-Policy should not specify those rules for composition.
>>>  
>>> It is not clear if example 1-5 are semantically equivalent just by 
>>> looking at their Qnames, even each Qname is well defined. Roughly 
>>> speaking, this is all WS-Policy about, i.e. represent literal 
>>> defined requirements by well defined individual Qnames and define 
>>> intersection rules to determine the semantics of composed Qnames.
>>>  
>>> Thanks,
>>>  
>>> - Wu Chou
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Doug Davis [mailto:dug@us.ibm.com]
>>> *Sent:* Monday, July 13, 2009 7:31 PM
>>> *To:* Chou, Wu (Wu)
>>> *Cc:* Bob Freund; Gilbert Pilz; public-ws-resource-access@w3.org; 
>>> public-ws-resource-access-request@w3.org
>>> *Subject:* RE: Issue-6692 - Interim agreement draft
>>>
>>>
>>> Wu,
>>>   In the original WS-E are these the same?
>>> Delivery/@Mode=".../PushWithAck"
>>> Delivery/@Mode=".../MyPushWithAck"
>>> Delivery/@Mode=".../WusPushWithAck"
>>> You need to understand the URI to know.  
>>>
>>> In your example:
>>>
>>> 1. <Push/><Ack/>
>>> 2. <Push><Ack/></Push>
>>> 3. <Ack/><Push/>
>>> 4. <Ack><Push/></Ack>
>>> 5. <myDelivery><Push><Ack/></Push></myDelivery>
>>> is no different. You need to know/understand the QNames to know if 
>>> they're the same.  
>>>
>>> If the definition of the URIs or QNames above are unclear then the 
>>> problem lies with the loose definition of those values - not in the 
>>> xs:any they're using.
>>>
>>> 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.
>>>
>>>
>>> *"Chou, Wu (Wu)" <wuchou@avaya.com>*
>>> Sent by: public-ws-resource-access-request@w3.org
>>>
>>> 07/13/2009 05:55 PM
>>>
>>> 	
>>> To
>>> 	"Gilbert Pilz" <gilbert.pilz@oracle.com>
>>> cc
>>> 	"Bob Freund" <bob.freund@hitachisoftware.com>, 
>>> <public-ws-resource-access@w3.org>
>>> Subject
>>> 	RE: Issue-6692 - Interim agreement draft
>>>
>>>
>>>
>>> 	
>>>
>>>
>>>
>>>
>>>
>>> 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_ <mailto: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_ 
>>> <mailto: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_ 
>>> <blocked::mailto:wuchou@avaya.com>
>>> */From/*/: Bob Freund <//_bob.freund@hitachisoftware.com_/ 
>>> <mailto:bob.freund@hitachisoftware.com?Subject=Re%3A%20Issue-6692%20-%20Interim%20agreement%20draft&In-Reply-To=%253CFDF27172-5127-4D9C-B7BC-B2CAC4D83697%40hitachisoftware.com%253E&References=%253CFDF27172-5127-4D9C-B7BC-B2CAC4D83697%40hitachisoftware.com%253E>/> 
>>> *
>>> Date*//: Mon, 6 Jul 2009 13:43:03 -0400*
>>> Message-Id*//: 
>>> //_<FDF27172-5127-4D9C-B7BC-B2CAC4D83697@hitachisoftware.com>_/ 
>>> <mailto:FDF27172-5127-4D9C-B7BC-B2CAC4D83697@hitachisoftware.com>/ *
>>> To*//: //_public-ws-resource-access@w3.org_/ 
>>> <mailto:public-ws-resource-access@w3.org?Subject=Re%3A%20Issue-6692%20-%20Interim%20agreement%20draft&In-Reply-To=%253CFDF27172-5127-4D9C-B7BC-B2CAC4D83697%40hitachisoftware.com%253E&References=%253CFDF27172-5127-4D9C-B7BC-B2CAC4D83697%40hitachisoftware.com%253E>/ 
>>> /
>>> 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_
>>>       <http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/att-0002/wseventing-6692-9-1.doc>
>>>
>>>     * application/pkcs7-signature attachment: _smime.p7s_
>>>       <http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/att-0002/smime.p7s>
>>>
>>>