RE: too many extension points (was Re: [Bug 6692] New: Remove Mode from the specification)

Removing Mode attribute/fault from WS-E specs is not the namespace URI
type change that impacts only content classes. It will break the
semantics of existing WS-E apps and implementations. We are more than
happy to chat with you to further explain these technical issues
described in our use case and emails. You can pick a time and we  can
go from there.

Thanks,

- Wu Chou.
  

________________________________

From: public-ws-resource-access-request@w3.org
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Gilbert
Pilz
Sent: Friday, April 10, 2009 2:04 PM
To: Chou, Wu (Wu)
Cc: David Snelling; public-ws-resource-access@w3.org; Doug Davis; Bob
Freund; Li, Li (Li)
Subject: Re: too many extension points (was Re: [Bug 6692] New: Remove
Mode from the specification)



I still don't know what you mean by "break the existing WS-E
applications and implementations". As has been stated many (many, ...)
times before, the change to the namespace URI already "breaks" current
implementations of WS-E. Leaving @Mode in isn't going to magically allow
existing WS-E implementations to understand the new, W3C namespace.

It seems to me that your objections are not about the binary,
broken/non-broken distinction, but about the degree and number of code
changes required to support this proposal. If this is the case, perhaps
we could have a dialog about the amount of code changes that are
acceptable to you? Given some of Avaya's previous proposal to
WS-Eventing it would appear that you do not hold a "change absolutely
nothing" position. Is that correct?

- gp

Chou, Wu (Wu) wrote: 

	Sorry to be repetitive.
	 
	The current WS-E specs fully support using all the other options
described in Gil and Dave emails. To use SOAP header or the Mode
attribute of WS-E is an implementation choice, and an implementation can
choose one or even use both for the application needs.
	 
	However, removing Mode attribute/fault of WS-E (issue 6692) will
force implementation to only use SOAP header, and break the existing
WS-E applications and implementations that follow the current WS-E specs
(detailed comments are in
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/00
33.html )
	 
	Thanks,
	 
	- Wu Chou.

________________________________

	From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
	Sent: Thursday, April 09, 2009 3:33 PM
	To: David Snelling
	Cc: Chou, Wu (Wu); public-ws-resource-access@w3.org; Doug Davis;
Bob Freund; Li, Li (Li)
	Subject: Re: too many extension points (was Re: [Bug 6692] New:
Remove Mode from the specification)
	
	
	Another place where @Mode is inferior is in the dynamic support
of extensions. For example, suppose I am an Event Sink that, for
whatever reasons, would prefer to acknowledge Notifications but would
still be willing to create a subscription even if the Event Source
didn't support acks (you can substitute any flavor of extension here).
Using @Mode you would have to:
	
	1.) send a Subscribe request with the "PushWithAcks" mode
	2.) handle the resulting "mode not understood" fault
	3.) send a Subscribe request w/out the "PushWithAcks" mode
	
	You have to do this because of @Mode's "fault on non-understood"
semantics. Using standard, XML extension mechanisms and our new, "ignore
extensions you don't understand" model, you could define an extension to
wse:Subscribe that meant "PushWithAcks" and a corresponding extension to
wse:SubscribeResponse that meant "AcceptPushWithAcks". Now all you have
to do to support the optional use of acks is to
	
	1.) send a Subscribe request with the "PushWithAcks" extension
	2.) look at the SubscribeResponse - if it doesn't contain a
"AcceptPushWithAcks" extension then the Event Source  didn't understand
the request to accept/process acks for Notifications
	
	Same result as above with one less round trip. Of course, as has
been mentioned numerous times before, if the Event Sink wanted the
"don't create the subscription if you don't understand this extension"
behavior, it could include a "UsingPushWithAcks" SOAP Header with
@mustUnderstand="1".
	
	- gp
	
	David Snelling wrote: 

		Gil, 

		Thanks for this discussion. It also brought something
back to my mind that has worried me about Mode. If in the end we keep
it, it will need to be enhanced to provide even the minimal required
support. Reasoning follows, very incomplete at this stage, but would
form the basis of a new issue should we retain Mode.

		So assuming Mode stays, we should encourage (at least
SHOLD) ALL extensions to the semantics of Eventing to use the same
mechanism. As soon as this logical step takes place, meeting the simple
queuing use case becomes problematic not to mention more interesting
cases. Where do we put queuing limits etc? The Mode attribute is only a
URI. As Gil points out there are a number of places to stuff extension
information, but to support Mode properly, we would need a
<wse:PutModeExtensionDataHere/> element so people could use the
extension points consistently.

		I don't want this can of worms opened at all, as the
specification starts to become very complicated (folks from the
WS-Notification WG will remember painful discussions when this kind of
bloat was discussed there). Eventing is a really good simple
specification with clean semantics. Retaining Mode in (a clean and
functional manner) will probably change all that.

		Please let's get rid of Mode.


		On 03 Apr 2009, at 21:31, Gilbert Pilz wrote:


			Let's look at the schema for the wse:Subscribe
message and it's included DeliveryType element (I've taken the liberty
of highlighting the existing extension points - you need to view this as
HTML to see what I'm talking about):
			
			<xs:element name="Subscribe">
			  <xs:complexType>
			    <xs:sequence>
			      <xs:element name="EndTo"
type="wsa:EndpointReferenceType"
			
			                  minOccurs="0" />
			      <xs:element name="Delivery"
type="tns:DeliveryType" />
			      <xs:element name="Expires"
type="tns:ExpirationType"
			
			                  minOccurs="0" />
			      <xs:element name="Filter"
type="tns:FilterType"
			
			                  minOccurs="0" />
			      <xs:any namespace="##other"
processContents="lax"
			
			              minOccurs="0"
maxOccurs="unbounded" />
			    </xs:sequence>
			    <xs:anyAttribute namespace="##other"
processContents="lax" />
			  </xs:complexType>
			</xs:element>
			
			<xs:complexType name="DeliveryType"
mixed="true">
			  <xs:sequence>
			    <xs:element ref="wse:NotifyTo" minOccurs="0"
maxOccurs="1" />
			    <xs:any namespace="##any"
processContents="lax"
			            minOccurs="0" maxOccurs="unbounded"
/>
			  </xs:sequence>
			  <xs:attribute name="Mode" type="xs:anyURI"
use="optional"
	
default="http://schemas.xmlsoap.org/ws/2004/08/eventing/DeliveryModes/Pu
sh" />
			  <xs:anyAttribute namespace="##other"
processContents="lax" />
			</xs:complexType>
			    
			If I was a developer interested in extending
WS-Eventing, I would find this situation confusing. Ignoring the fact
that the wse:NotifyTo element is an EPR and can itself be extended,
there are five (5) different ways I can extend the wse:Subscribe message
(or, if you count element/attribute extension of the same element as a
"single way", there are three (3)). What makes this even more confusing
is that not all of these extension points have the same processing
rules. The XML extension points (in black-bold) are subject to the
following, recently accepted, language:
			

				The elements defined in this
specification MAY be extended at the points
				indicated by their outlines and schema.
Implementations MAY add child elements
				and/or attributes at the indicated
extension points but MUST NOT contradict the
				semantics of the parent and/or owner,
respectively. If a receiver does not
				recognize an extension, the receiver
SHOULD ignore that extension. Senders MAY
				indicate the presence of an extension
that has to be understood through the use
				of a corresponding SOAP Header with a
soap:mustUnderstand attribute with the
				value "1".
				  

			Whereas the WS-Eventing specific extension point
(in blue-bold) is subject to the following:
			

				If the event source does not support the
requested delivery mode, the request MUST fail, and the event source MAY
generate a wse:DeliveryModeRequestedUnavailable fault indicating that
the requested delivery mode is not supported.
				

			I think the common reaction to this situation
would be "WTF <http://thedailywtf.com/Default.aspx> ?" This needs to be
simplified so that, if you want to extend WS-Eventing, you aren't
required to navigate through a maze of different extension points that
may or may not result in different processing behavior (i.e. "What is
the difference between extending /wse:Subscibe/wse:Delivery or just
/wse:Subscribe?").
			
			Clearly the "Mode" attribute, with its
conflicting semantics, should be removed. In addition to this, we need
to remove the "Delivery" element and it's extension points (obviously we
would move the wse:NotifyTo element up into the wse:Subscribe element).
What we would be left with would look like this:
			
			<xs:element name="Subscribe">
			  <xs:complexType>
			    <xs:sequence>
			      <xs:element ref="wse:NotifyTo"
minOccurs="0" maxOccurs="1" />
			      <xs:element name="EndTo"
type="wsa:EndpointReferenceType"
			
			                  minOccurs="0" />
			      <xs:element name="Expires"
type="tns:ExpirationType"
			
			                  minOccurs="0" />
			      <xs:element name="Filter"
type="tns:FilterType"
			
			                  minOccurs="0" />
			      <xs:any namespace="##other"
processContents="lax"
			
			              minOccurs="0"
maxOccurs="unbounded" />
			    </xs:sequence>
			    <xs:anyAttribute namespace="##other"
processContents="lax" />
			  </xs:complexType>
			</xs:element>
			What you have now is really two ways to extend
the wse:Subscribe request. You can extend the wse:Subscribe message
(through either an attribute or an element) if you want an extension
that is specific to WS-Eventing, or you can extend the NotifyTo EPR if
you want an extension that operates at the WS-Addressing level (i.e.
across any technology that uses WS-Addressing).
			
			- gp
			
			Chou, Wu (Wu) wrote: 

				Doug,
				 
				Mode attribute in WS-E is to specify the
additional required event delivery behavior or required
application/business logic extensions that the event source must
understand/support before being allowed to accept the event
subscription.
				 
				My understanding is:
"push_event_thru_proxy" is for all events delivery from the Subscribe.
As such, it covers SubscriptionEnd event. The Mode attribute also allows
to specify fine grained application logic to control the event delivery.
If you want, more fine grained event delivery logic/procedure can be
easily added to Mode attribute to control the event delivery, e.g.
"push_thru_proxy_for_subscriptionend_event_only",
"push_thru_proxy_for_non_subscriptionend_event", etc. 
				 
				Mode attribute in WS-E provides a
standard extension point to add application specific logic and behavior
to event delivery, so that it can enforce the required procedure/logic
for business applications when using WS-Eventing for event delivery.
				 
				Thanks,
				 
				- Wu Chou.
				 
				>Wu,
				 > since its too easy for things to get
lost in these long messages, let me 
				focus on one particular aspect of this.

				 
				>Surely the idea of using a proxy 
				for sending messages is not WS-Eventing
specific.  How do you support 
				sending any other asynchronous message
(non-NotifyTo messages) thru a 
				proxy?  
				>Need a clarification on th, e.g. a
general question, a question for WS-E or a question for WS-E plus Mode.
				 
				>For example, the SubscriptionEnd
message.
				
				thanks
				-Doug
				
				 
				 
				Wu Chou, IEEE Fellow, Ph.D. | Director
|Dialogue System 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>  
				 


		
		
		
		
		Take care:

		    Dr. David Snelling < David . Snelling . UK . Fujitsu
. com >
		    Fujitsu Laboratories of Europe Limited
		    Hayes Park Central
		    Hayes End Road
		    Hayes, Middlesex  UB4 8FE
		    Reg. No. 4153469

		    +44-7590-293439 (Mobile)






______________________________________________________________________

Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
Registered No. 4153469

This e-mail and any attachments are for the sole use of addressee(s) and
may contain information which is privileged and confidential.
Unauthorised
use or copying for disclosure is strictly prohibited. The fact that this
e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield
does
not guarantee that it has not been intercepted or amended nor that it is
virus-free.