- From: Chou, Wu (Wu) <wuchou@avaya.com>
- Date: Fri, 17 Jul 2009 10:03:12 -0400
- To: "Gilbert Pilz" <gilbert.pilz@oracle.com>, <public-ws-resource-access@w3.org>
- Message-ID: <F81BDFA28AE48D4793E253362D1F7A740112ACD5@300813ANEX2.global.avaya.com>
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 there 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> <mailto: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> <mailto:gilbert.pilz@oracle.com> cc "Bob Freund" <bob.freund@hitachisoftware.com> <mailto:bob.freund@hitachisoftware.com> , <public-ws-resource-access@w3.org> <mailto: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-%20 Interim%20agreement%20draft&In-Reply-To=%253CFDF27172-5127-4D9C-B7BC-B2C AC4D83697%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-B 2CAC4D83697%40hitachisoftware.com%253E&References=%253CFDF27172-5127-4D9 C-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/a tt-0002/wseventing-6692-9-1.doc> * application/pkcs7-signature attachment: smime.p7s <http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/a tt-0002/smime.p7s>
Received on Friday, 17 July 2009 14:04:02 UTC