W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > April 2009

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

From: Doug Davis <dug@us.ibm.com>
Date: Sun, 5 Apr 2009 21:22:33 -0400
To: Gilbert Pilz <gilbert.pilz@oracle.com>
Cc: Bob Freund <bob.freund@hitachisoftware.com>, "Li, Li (Li)" <lli5@avaya.com>, public-ws-resource-access@w3.org, "Chou, Wu (Wu)" <wuchou@avaya.com>
Message-ID: <OFDC42787C.837D58B5-ON85257590.00053801-85257590.000791D5@us.ibm.com>
Huge +1 to the end result.

However, to be fair to the poor little picked on Mode attribute - I don't 
think its an extensibility point the same way a normal xs:any is.  While 
it can be 'extended' to allow for new Modes, you must pick exactly one 
when you Subscribe.  So, in that sense its slightly different.  But 
nonetheless I think its still a point of confusion, not only for the 
reason that have been pointed out so far, but for a whole new set that 
make it unusable (ie. fundamentally flawed).

First, let's not forget about what this WG has already decided.  In issue 
6425 [1] we decided that all messages are to be addressed to an EPR - and 
this includes Notifications.  So this, as Gil suggested, should force us 
to move the wse:NotifyTo out from under the Delivery element since it MUST 
always be there per 6425.

Second, there's an additional confusion point around Mode that we haven't 
talked about yet: how usable is it?  Let's look at Wu's "Proxy" example. 
He chose to define a new Mode to add some additional processing semantics 
to how Notifications are sent.  However, since the SubscriptionEnd message 
could need the same type of special processing, and since the EndTo 
doesn't have a Mode, we need to three (3) Modes: 1) apply Proxy to just 
Notifications, 2) apply Proxy to just SubscriptionEnd messages, 3) apply 
Proxy to both.   Let's take this one step further.  Say that someone else 
wanted to define another 'additional processing semantic' Mode.  Following 
the same pattern they would need to define their own three (3) Modes. Now, 
here's the really bad part, what if someone wanted to use them both at the 
same time?  Someone would have to define nine (9) different Modes to cover 
all possible combinations.  This "extensibility point" just isn't scalable 
or usable.  It doesn't allow for independent "modes" to be used even 
though they could be defining totally non-overlapping semantics. 

In Gil's note he actually missed another extensibility point - the SOAP 
envelope itself - in particular the use of mU headers. In one of my 
previous notes to Wu I pointed out that through the use of mU headers he 
could add his Proxy support and get the same functional end result.  He 
can either put all of the semantics in the mU header or he could add some 
additional elements to one of the extensibility points under the 
wse:Subscribe and use an mU header just to make sure those new elements 
aren't ignored.  Either way, this allows for any number of extensions to 
specified without each needing to know about the other and without the 
explosion of Modes I talked about above. This is a much cleaner, feasible 
and scalable solution than what Mode currently provides.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=6425

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.

Gilbert Pilz <gilbert.pilz@oracle.com> 
04/03/2009 04:31 PM

"Chou, Wu (Wu)" <wuchou@avaya.com>
public-ws-resource-access@w3.org, Doug Davis/Raleigh/IBM@IBMUS, Bob Freund 
<bob.freund@hitachisoftware.com>, "Li, Li (Li)" <lli5@avaya.com>
too many extension points (was Re: [Bug 6692] New: Remove Mode from the 

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 
<xs:element name="Subscribe">
      <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:anyAttribute namespace="##other" processContents="lax" />

<xs:complexType name="DeliveryType" mixed="true">
    <xs:element ref="wse:NotifyTo" minOccurs="0" maxOccurs="1" />
    <xs:any namespace="##any" processContents="lax"
            minOccurs="0" maxOccurs="unbounded" />
  <xs:attribute name="Mode" type="xs:anyURI" use="optional"
http://schemas.xmlsoap.org/ws/2004/08/eventing/DeliveryModes/Push" />
  <xs:anyAttribute namespace="##other" processContents="lax" />

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

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: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:anyAttribute namespace="##other" processContents="lax" />
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 

- gp

Chou, Wu (Wu) wrote: 
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.
- Wu Chou.
 > since its too easy for things to get lost in these long messages, let 
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 
>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.

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 
Received on Monday, 6 April 2009 01:23:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:48 UTC