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

I am sure that most would agree that a namespace change is less  
perturbation, and expected at that, than more extensive re-engineering.
What I am hoping to see is some give and take, not take it or leave  
it, on all sides of these arguments.
Folks, lets make the debate constructive and technical.
One micro-point at a time.
I am very patient, but I can't alone get folks to get to the details,  
understand them and weigh their technical merits.
There will surely be technical disagreements as well as disagreements  
based on how one personally weigh various factors such as perceived  
installed base, momentum, side of the crowd you think agree with your  
proposals and so forth.
The conviction of your opinions should not cause one to not consider  
and accommodate the needs of others.
-bob


On Apr 10, 2009, at 1:03 PM, Gilbert Pilz wrote:

> 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/0033.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/Push 
>>>> " />
>>>>   <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?"  
>>>> 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
>>>>>
>>>
>>> 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.