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