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