RE: Issue-6692 - Interim agreement draft

Wu,
  your main point appears to be centered around this paragraph:
These constraints are important for interoperability, because the delivery 
mode is an anchor point for other extension elements. To process other 
elements in xs:any, it needs first to determine the delivery mode, e.g. 
Push or Pull, before being able to establish the semantics of other 
extensions, e.g. allowed or not allowed, etc. Determination of Mode in 
original WS-E is straightforward, since it is either the default ?Push? or 
the one given by the @Mode URI.
I would recommend that you reread the member submission of ws-eventing 
because none of this is true.  WS-E did not make @Mode more important than 
the xs:any's.  Nor did it say that any of the xs:any's under Delivery are 
scoped by the @Mode attribute.  But even if it did, there are other 
xs:any's that could be used instead. In particular it would be very legal 
to say @Mode="push" and then have <pull/> in one of the xs:any's - the 
service would still need to either figure out what it meant or figure out 
that there's a conflict and fault.  Because of this, all of your "issues" 
(if they exist) were there in the original WS-E, they're still there now, 
they're still there in your ws-policy based proposal, and they will always 
be there unless we remove ALL extensibility points in the spec.

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/21/2009 11:40 AM

To
"Gilbert Pilz" <gilbert.pilz@oracle.com>
cc
<public-ws-resource-access@w3.org>
Subject
RE: Issue-6692 - Interim agreement draft






Gil,
 
The original extensibility model in WS-E for delivery element consists of 
two parts, i.e. one through Delivery/@Mode URI and one through the xs:any. 
In WS-Eventing, @Mode is at a higher semantic hierarchy and it provides 
the critical context, e.g. Push, Pull, etc., for processing other 
extension elements. 
 
For example, it has a default value ?Push?, the default value can only be 
changed by Delivery/@Mode URI, and extension elements in xs:any should not 
contradict or overwrite the delivery mode.
 
These constraints are important for interoperability, because the delivery 
mode is an anchor point for other extension elements. To process other 
elements in xs:any, it needs first to determine the delivery mode, e.g. 
Push or Pull, before being able to establish the semantics of other 
extensions, e.g. allowed or not allowed, etc. Determination of Mode in 
original WS-E is straightforward, since it is either the default ?Push? or 
the one given by the @Mode URI.
 
When using Qnames for delivery mode extension and lump them with other 
extension elements in xs:any, the original extensibility structure of WS-E 
is no longer there, and it introduces the following issues:
1.     It is unclear how to determine the semantics of expressions 
(combinations) formed by Qnames in order to establish the delivery mode, 
and what algorithm should use to parse and determine the delivery mode 
from xml block under xs:any. 
 
2.     For example, the expression <Push /><Pull  /> can be interpreted 
as: 1) Invalid, since both <Push  /> and <Pull  /> occur; 2) <Pull  /> 
since <Pull  /> is after <Push  /> and therefore, overwrites <Push  />; 3) 
two supported delivery options of <Push  /> and <Pull  />, since there is 
no mU header; etc. It is unclear how a subscriber should do to indicate 
using either <Push  /> or <Pull  />, but not both. This issue is acute for 
more complex expressions, e.g. <Push  /><Pull /><Push />? <Push /><Pull 
/><Push /><Ack />? ...
 
3.     It is unclear how the event source should define and specify the 
permissible Qname expressions (combinations) so that the subscriber knows 
which one to use for a particular event source.
 
4.     It is unclear how an event source should satisfy both optional and 
non-optional requirements and how the event sink can know which particular 
combination of requirements that the event source apply/use in its event 
delivery. For example, when optional delivery Qnames, e.g. Push, Pull, MC, 
etc., are used, the event sink has no clue which particular delivery 
option that event source uses to send the notification even receives a 
positive response. This will cause the notification to break.
 
5.     How do we constrain the mode changing QNames so that it does not 
incur huge overhead for the event source to process it?
 
6.     The composition in the generic SOAP extension is somewhat different 
from the QName composition here. In generic SOAP extension, different 
extensions are independent in the sense they can fit into a Chain of 
Responsibility design pattern (where each extension is implemented by an 
interceptor). Whereas no such effect exists  here and all QNames have to 
be processed as a whole, and the delivery mode may need to be determined 
first in order to process and deliver the notifications correctly.
...
 
Therefore, a WS-Policy based framework for delivery mode extension become 
critical ...
 
- Wu Chou

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Friday, July 17, 2009 2:40 PM
To: Chou, Wu (Wu)
Cc: public-ws-resource-access@w3.org
Subject: 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 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> 
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