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>
>
>